The Importance of Sharing Expectations

Today I finished the Design Kit Prototyping Course, offered by and +ACUMEN. Although the course was run online, most of the work took place offline, because the course required to form a team of fellow students located in the same area and work on the course’s assignments together in workshops.

I didn’t only like the fact that the group-guided aspect supports the prototyping process which is enriched by testing and getting feedback from others, I also became curious about learning from my teammates, their ideas, thoughts and reactions as collaboration with different kinds of people is besides prototyping an essential skill for UX design.

So it happened that my London-based team and I met over a period of four weeks to work together on different problems and solutions regarding health, the course’s overall topic.


All in all, I had a good experience: I had the chance to work with some inspiring people on some very meaningful ideas. Nevertheless, I became frustrated over time.

Exploring the source of frustration

What I always start doing when I feel frustrated is analyzing myself: What exactly makes me frustrated? Am I not interested in the task? Am I not capable to solve a problem? Is this just not my thing?

All these assumptions turned out to be wrong. As already mentioned, seen as a whole, the experience was good. I really enjoyed thinking on big and small ideas together with other people, coming up with ideas on my own, writing lots of sticky notes while doing brainstorming sessions and finally prototyping experiences and having the chance to get feedback from real users.


While the course showed me how I can use tools and methods to get things done, I learned from working within a team how to structure workflows and meetings by becoming the project lead.

I’m also more certain than ever, that design is the thing that really fascinates me, and which I want to do for a living.

However, the experiences during the course left me disappointed to an extent. Why is that?

Meeting expectations

The question I’ve forgotten to ask is a very basic one, but one I now put on the very top of the list when I analyze frustration:
Have my expectations been met?

This questions of course involves another question to be clear about:
What are my expectations?

In case of this course, my expectations were very clear as it was a task to define them at the beginning of the course.

I expected the course to teach me the method of prototyping by providing me with essential guidance and tools to practice the prototyping process, including building prototypes, testing/getting feedback and iteration.

The issue of different expectations

When I reviewed my expectation after two weeks of course work with my teammates, I realized that their expectations are not the same:
While I intended to use the course to practice the method of prototyping, my teammates’ goal was to develop realistic ideas.

It turned out that my disappointment derives from my expectations which couldn’t be met because my teammates moved into a completely different direction.

This led to some complications during the course work which caused this disappointment in a more practical way. Here are three examples:

Being unclear about tasks and goals

In the very first meeting, talking about goals and the course’s structure was difficult because my team members haven’t read the course material and assignment instructions. As a result, we spent time on discussing what the overall topic for our ideas should be, although it was already determined by the course.

Deprioritizing the prototyping action

In the next workshops, we concentrated on polishing our ideas. We made sure that they really meet users’ needs and are technically feasible by doing lots of desk research at home and discussing our results in the team. We finally came up with an idea that is too complex to prototype. So the actual prototyping was postponed from session to session which forced us to miss assignment deadlines.

Doubting the value of the course

My teammates were consequently pushing towards applying their own practices and approaches instead of following the course’s structure and requirements which consequently led to the decision to not continue the course by ignoring its assignments.

The third example was finally the point where it became obvious to me why working with this team was so hard. The lack of commitment to the course explained why no one has read the course material and understood what the course is about. Because for my teammates, it was never about taking and completing this course. It was all about working on ideas within a group and maybe creating something for their portfolio.

I still don’t understand why people take a course when they don’t have the intention to actually do it. There are other ways of finding folks to discuss ideas with, like meetup groups for example. 
Taking advantage of a course which is as predetermined as this prototyping course in order to push through one’s own purposes is in my eyes unfair to people who want to learn from what the course has to offer.
But this is not supposed to be the topic of this post, so I will stop here.

What’s more important is that I understood what drives my frustration and that I can now learn from it for the next project.

Share your expectations with the team at the beginning of a project

The problem was not that my teammates had different expectations. The problem was that we didn’t share them at the beginning of our collaboration.

While my teammates seemed to be lucky and found other team members that share pretty much the same expectations, this wasn’t the case for me.

Not having shared our expectations from the very beginning led to two kinds of inefficiency I experienced during the course:

  • Inefficiency regarding unmet expectations
    e.g. not being able to practice the prototyping process within the given time

  • Inefficiency regarding team work
    e.g. time wasting discussions on what to do and how to do it, reviewing goals, deciding on methods

This inefficiency didn’t only cause frustration for me, it also slowed down the workflow. Sharing expectations can therefore be regarded as one of the key principles of successful projects.

Where sharing expectations matters

If we transfer my key takeaways from the course to the business of designing user experiences, the sharing expectations rule becomes important at two different stages:

  • When you start working with your team of stakeholders, clients and teammates
  • When you tell your users what they can expect from your product

1. When you start working with your team

The experience from the prototyping course taught me that sharing expectations is essential to avoid demotivated team members and disorganized workflows.
What seems to be a standard but insignificant component of a kick-off workshop suddenly makes a lot of sense.

  • Sharing expectations feeds the project goal with details.
  • By sharing exceptions, team members can learn from their teammates’ different perspectives on a project which broadens their understanding of the problem to solve.
  • Sharing expectations also means sharing practices, tools and methods team members consider important to lead a project to success.

Dealing with different expectations

If it turns out that the shared expectations are pretty different like in the case of my course, this won’t make the project fail. Instead the team can benefit from this insight by finding a way of collaboration that respects different expectations.


Being aware of different expectations also helps individuals to be prepared for the upcoming weeks of project work and therefore decreases the risk of disappointment as a result from unmet expectations.

Finally sharing different expectations encourages a more frank discussion in the team and can even raise the question whether a cooperation under the given conditions is worthwhile.
In the case of my course, after knowing about my teammates’ different expectations, I might have switched the group.

Sharing exceptions therefore doesn’t only make team members more satisfied when performing on a project, it also makes the workflow much more smooth by agreeing together on the kind of outcome and ways of achieving it.

2. When you tell your users what they can expect from your product

When I found which extremely negative effect unmet expectations on my project satisfaction had, I became a little bit nervous regarding designing for users:

How might a user feel when she realizes that her expectations couldn't be met after buying a product?

We can find user frustration everywhere today, whether on a company’s Facebook page, in emails and call centers or person-to-person. And these reactions don’t yet include the large number of frustrated customers who prefer to not share their negative feelings about a product.

Assuming that these complaints are caused by unmet expectations, companies should not only pay attention on designing better products, but also on communicating the product’s purpose from the user’s perspective.

This involves several guidelines about how businesses should deal with user expectations – from user research to value proposition to advertising.

1. Make clear which jobs users can get done by using the product

Every good product evolves from a task or a problem a user faces. According to Clayton Christensen’s “jobs-to-be-done” framework, people hire a product to get a job done. If the product fails to help them to get this job done, this could be clue that either designers concentrate on the wrong job, or the benefits users can gain from buying the product are explained incorrectly.

On the other hand, finding out that users use a product for completely different jobs than designers have expected could indicate new business opportunities.

In each case, businesses should align job and product by following the steps below:

  • Find out what the job is
  • Define how the product could help to get this job done
  • Shape the product into this direction
  • Explain job and benefits as clearly as possible from the user’s perspective

2. Show the outcome so that users see what they can expect

Related to Clayton Christensen’s theory, people don't buy a product to get a product. They buy a product to achieve something within a wider context. That’s why Apple shows pictures taken with the iPhone's built in camera in their “shot on iPhone” ad campaign instead of overwhelming users with technical details.


In her book “Badass: Making Users Awesome” Kathy Sierra drives this argument even further by disclosing an important secret: When users say “This product is awesome”, they actually feel “I am awesome because of this product”. The less practical version of this is: Users don’t care so much about a product, brand or company. They care about themselves and what the product enables them to do or be.

Hence, showing the outcome users can achieve by using a product makes this product a lot more attractive, but it also conveys a clearer promise. Being explicit in the value proposition and offering plausible examples of users’ results helps to avoid false and finally unmet expectations.

3. Encourage users to share their (unmet) expectations and react to them

If a product or experience misses users’ expectations, the first step to solve this problem is to listen to frustrated users. Ask them what they have expected, what their task is and which part of the product they thought is helpful for that but finally caused disappointment.
Be concrete when gathering feedback so that it can effectively inform design changes. Also make sure that more than one user will benefit from these changes.

This of course requires a way of collecting feedback, at least to discover that some users found their expectations unmet. While user testing is always desirable, designers can also reach out to internal stakeholders and departments who have direct contact to users like sales, customer service or marketing. Probably lots of feedback has been already collected via the company’s communication platforms like email and social media, and is waiting to get analyzed.

However feedback is gained, the point is finally to encourage users in an honest way to share their existing, met and unmet expectations in order to improve their experience.


Not having shared expectations had an unforeseen bad impact on my course experience which finally caused me to write this blogpost, which also served as a way of dealing with feelings like frustration, so sorry for any bleating.

But at the end, this experience made me aware of the importance of sharing expectations in different contexts of product and UX design: On the one hand directly transferred to working with teams on projects, and on the other hand more indirectly connected to dealing with user expectations in human-centered businesses.