Every project we do at Natural Interaction starts with discovery. This phase is probably my favourite because it’s about gathering evidence. Like Sherlock Holmes, we go about finding the information we need to solve our client’s problem.
We meet with the key stakeholders to workshop and ask questions, and we speak to users about what they expect that thing to do. We interrogate (in a friendly way) and listen to their frontline staff at work and perform in-depth interviews with key stakeholders.
Discovery is about finding out what the client wants for their customers, what their customers actually want and what their staff want. By having everyone aligned on one end goal, you’ll find that the product, no matter how complex, will be better as a result.
You’ll also find that running discovery enables braver creativity. This is the time to suggest innovative design ideas because at that point, there are no limitations to the various possibilities ahead.
A word of warning – that doesn’t mean you can go wild with your design. You still need to be careful to ensure that those first creative ideas at least point to solving the problem ahead. That you’re making the right assumptions and staying within the client’s budget.
Taking the time to run a successful discovery phase will always result in a stronger outcome. Do not start designing until you’re confident you know the client and their product inside out. That you have some clear testable assumptions about what it should do and who its users will be. And most importantly, that your client is engaged with what you’re doing.
Having everyone on the same page is invaluable when it comes to designing the right thing for the right people the first time around. We start with the stakeholders on every software design project. Who should we be talking to? Who’s involved and what do they want to happen?
Not sure about how to run a discovery phase? We split it into these six parts.
A chance to get everyone to sit down and discuss the approach and schedule ahead. As the first meeting, this is also the time to introduce yourselves properly and start to get to know the people you’re working with.
Typically, software design projects can last upwards of six months so you’re going to spend a lot of time together. You’ll come away with some handy meeting notes, early insights and agreed next steps for future workshops and collaboration opportunities.
These one-on-one in-depth interviews help you get to know the various decision makers on the project. Understanding their vision and goals for the end product will arm you knowledge which will come in useful when user testing later on. Be warned, often different stakeholders have different goals for the same product. The sales team for example, may want to use it in a different way to the service department.
These interviews tend to last between 45minutes – 1 hour and we do them either face to face or through video conferencing. Upon completion, you can use the information gathered to create a list of key themes and topics.
What does success look like? That’s the question we set out to answer in this workshop, building a shared understanding of the goals of the project and defining how to measure end success. We also prioritise goals based on user and business needs. At the end of the workshop, everyone will have clear, defined objectives to work with.
A proto-persona workshop builds a shared understanding and assumption of who the end product is intended to serve and what the needs, goals, attitudes and behaviours of its users are. Proto-personas differ from regular personas because they tend to come out of a team meeting before users are involved. They are useful as a starting point, based on the expertise and business understanding in the room at that time, but eventually should be replaced with evidence-based personas.
A deliverable here would be a set of quickly sketched proto-personas and empathy maps. These can be used to inform project decisions as you move into the design phase.
Again, in a workshop environment, we’ll work together with key stakeholders to pull together a list of ‘jobs to be done’ from both user and business perspectives. This is a great way to capture all the user and business needs upfront without being prescriptive about how to implement them at this early stage. This also allows for creativity in the design phase.
A typical ‘job to be done’ would include a situation, motivation and expected outcome for example: “When I visit the Natural Interaction website from my phone I want to be able to get information about their UX design services so I can learn more about what they do.”
In the early stages of a project, it’s important to take a step back and focus on the overall view of what you’re working on. Sometimes taking a broad quantitative approach at this point can help ensure you’re on the right track. The data you collect from a user survey can help you to see user behaviour on a wider scale. You can see more about who they are and any common themes.
If we’re working on a redesign or adding new features to an old piece of software, we’ll often run a round of usability testing on the existing piece. This highlights anything the users particularly struggle with but also anything which is positive and could stay as is in the new design.
Much like the stakeholder interviews, talking with users one-on-one will help you to explore their problems with either the existing product or those that the new product is aiming to fix. If your client has persona groups, try to speak to someone from each segment to give you a strong overview from all angles. You’re likely to uncover issues and frustrations as well as preferences you and the key stakeholders had no idea about.
Discovery is about learning as much as you can from all angles and speaking to users directly might just spark design inspiration before you’ve even opened that fresh Sketch file.