Way of Working


03 March 2021 • 5 minutes

Written by Eban Escott

Way of Working title image

Once you understand the problem more, the team now can move onto one of the most important stages that is often over looked, Observe.

Observe is the stage where the team goes out with the problem and knowledge of who the audience is and begins to watch how it affects them. One of the best ways to prevent the project from not providing value, is not validating or disproving assumptions the team has made. Often those who have come up with the problem are not the ones being affected by it and only have second hand experience with it. By getting down and talking to people you can pick up on things that you would never have thought about.

Project cycle

Design Thinking Cycle

The Observe and Understand stages of the scope are often done at the same time or sometimes even in reverse. This is because there are cases where you want be proactive and observe your users to find problems they are facing in order for you to fulfil their needs. In most cases you’ll start off with the problem and work from there.

After the team has defined the problem and identified what people need to be spoken to as both target users and domain experts, it’s time to start the interviews. This where you can start to unpack the problem and see how it is affecting people, get to the bottom of what they think, and try to empathise with them. Watch what they do to get around the problem, that might even be a good direction for your solution. After speaking with the users it is time to do some research into the market to see how competitors (if any) are tackling the problem or a similar issue.

Gather as much knowledge as possible and start to look for patterns in the data. This is where you as a team can start to refine what the problem is a bit more. Perhaps the original problem was too off the mark for the users or perhaps you found a new and more critical problem that should be looked at first. With all those recommendations it is time to start Ideating on solutions.

Observing the users and market

There are a few key things to do and remember while you are in the Observe stage of the project:

Interviewing people

Interviewing your users is one of the most powerful and effective ways to ensure you and your team are on the right track. All to often this part of the scope is dropped for time or resources, and the flow on effect from it is felt for months. By spending just a few hours at the start of the project and trying understanding why the problem is an issue, you gain amazing insight into what the solutions can be. Rather than taking a stab in the dark, hoping your experience and best guess can solve something for someone you’ve never met.

Observing actions

By watching what people do and how they go about solving the problem on their own, you can find some really interesting and novel ways to create a solution. People are always trying to create work-arounds for issues, and even understanding how they came to that conclusion can give you insight into what they are naturally going to try and do with your solution. As a team, your job in this stage is to absorb as much about your target audience as possible and get into their minds. Get out and about and really gain an understanding.


Alongside just speaking and watching people, this is the prime time to start researching into the problem and the market itself. Looking to see how and what other people did to try and solve your problem or a similar can give you an amazing head start. If your competition does something one way and their users love it, why reinvent the wheel if that is what people are used to. Instead look for ways to improve that same solution.

Gaining empathy

One of the most important and powerful tools for solving problems is empathy. As a team it is important to really understand how the problem is affecting users. Understand why they are frustrated or how a possible solution will improve their lives. A great example of this is the AirBnB team who went out and travelled for a short while using their own system to see how it works out in the wild. Feeling the same frustrations their users felt with checking in and what to do in the locations.

Looking for patterns

Part of being a good researcher is being able to look for patterns and understand why somethings come up again and again. By learning more about your users, you can start to see patterns emerging in their answers and actions. These patterns can help influence your solution as it could be a shared theme your users are looking for in your product. If they all naturally go one way, don’t make a solution that forces them to go another way.

Redefining the problem

At the end of your initial observation of users, it is a prime time to come back and revaluate your problem statement. Perhaps from your learnings you find that the problem is not in fact a real problem for your users, another one is. Perhaps you can refine the problem down more and target a smaller issue. There is also a good chance you have validated your problem and you can all be assured you are on the right path to impact peoples lives. Don’t be afraid to change your problem statement as you learn more, but make sure you inform everyone in the team of the change and are happy with the new direction. There is nothing worse than deciding to not change the statement after learning it was not the true issue, spending weeks and months solving it, launching it and no one actually wanting your solution!

Activities to try

To help you find the best answers to your questions here are a few activities you can do to gather information.

Pattern recognition

Pattern Recognition - Here you can learn more about ways to find patterns in your research and how to group them into meaningful findings.


Market research - Fold into secondary research

Analogous research - Fold into secondary research

List of assumptions - Fold into jobs to be done

Film & sound - Found into secondary search

Bundle ideas - Fold into finding themes

Red routes - Fold into prioritising

Priority grid - Fold into prioritising

Observation - Fold into secondary research

Card sorting - Fold into jobs to be done

Eban Escott

Written by Eban Escott

Founder of Codebots

Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.