Often people start with ideas for projects and apps (both web and mobile), confident that their pre-existing knowledge, experience and project goals are enough to get going - however this is rarely the case.
We’ve helped customers through this journey, and we’ve always found that a period of exploration at the start of a project is needed. This helps us understand the customer’s domain more clearly while also helping clarify objectives, constraints and assumptions. This process allows us, working together, to expand initial ideas to be the best they can be.
Why start with a discovery process?
Some people call this early part of the design process ‘research’, or ‘definition’, but I prefer ‘design discovery’. It’s not a prescribed series of steps, but more a process, usually different every time, that helps you learn about your target audience and your business goals, improve existing ideas, generate new ones, and help you see the problem more clearly.
Our customers are usually experts in their particular field, and one of the things that comes with expertise is an almost instinctive understanding of how their business-space works.
However, the more one becomes an expert the harder it is to get into the mindset of someone who is new to the field. Methods that involve gaining insight into user’s perspective are really important, as otherwise you end up making something that only expert users can use.
Most of the discovery methods we use aim to bridge this gap in some way.
What design discovery methods should I use?
Whole books have been written on the subject of design discovery, far more than a single blog post can cover, but here’s a high level overview of some of the things we use at the start of projects which really help frame things and ensure we are delivering value in the right areas. It’s not a prescriptive list, and often we choose what is most appropriate for any given situation.
This is where we get together with the customer for a half-day / full day to explore ideas. Rather than focus down on a single idea and hone it, we explore things in a more divergent way, throwing different ideas up on the wall and seeing what sticks. It’s a real collaborative way of exploring things in a lo-fi way, and gets people scribbling out ideas for interfaces and exploring things from the user’s perspective.
- Empathy maps & user journey mapping - helping get you into the mindset of the user and identifying pain points a user might face before, during and after using your app.
- 6-up sketching (rapid exploration of different user interfaces with pen and paper).
When might you use this?
When you have an idea for a new project, but haven’t done any user research. When you have an existing app that might not be as effective as it could be, and needs redesigning with the user in mind.
This is often a short workshop, backed up with prior competitor research, that helps customers explore who they are and what their values might be, what they stand for, and exploring why users should use your app over competitors. We find exercises like these really sharpen focus, and often the output can be used to guide future decision making, as well as inform the voice and tone of words you use.
We often produce brand style guides for clients as an output of these exercises, which feed directly into app development.
- Brand value exercises regarding voice, tone and personality.
- Writing an ‘elevator pitch’ to help distinguish you from your competitors.
- ‘Designing the box’ - as if your app was a physical product - which helps prioritise features.
- Competitor research - a deep dive into what else others are doing and how you can position yourself accordingly.
- Identity design - looking at visual brand and exploring brand design.
These are all used to prioritise what’s important to your brand, differentiate yourself from others and provide a laser focus on how you portray yourself to your users in both identity and tone.
When might you use this?
Often these exercises are used when people are starting out with a new idea, and haven’t delved down into their brand. These can also all be helpful in cases where apps haven’t had any thought given to content, voice, tone and visual identity.
While we are all experts in our various fields, our apps are not really used by us, but by people using our services. For all the expertise and domain knowledge we can apply to designing user interfaces, we don’t ever truly know whether something is going to be effective until we put it in front of users.
The good news, however, is that by creating a prototype before the development phase (essentially faking out the user interface using a prototyping tool like Marvel) we can test both comprehension and aspects of task completion before we start development, allowing for easier and less costly adjustment of designs at an earlier stage.
Moderated user testing - running users through tasks, and assessing understanding and completion rates, identifying issues with your designs.
When might you use this?
There’s no real downside to performing user testing, other than the challenges of recruiting users and time/cost, but it’s well worth it, saving you money in the end by making a product that is easier to use and costs less to support. User testing is something that can be done very much on a sliding scale, from larger more rigorous testing sessions in usability labs to guerrilla usability testing on a more lo-fi scale.
Whatever your budget, it’s important to do some kind of user testing to validate your ideas - most products that you use daily have gone through periods of user testing and changed/pivoted into what they are today as a result.
Choosing the right discovery methods
As you can see from the whistle stop tour above, there are many things one can do to gain insight into both product ideas and direction.
If you need guidance as to what might be most effective and useful for your project, do get in touch - our design team is always happy to help plan and run initial exploration phases with you before any development is undertaken, ensuring what you make is the best it can be.