The teams working on Data Infrastructure at GDS have just completed three discoveries. We’ve walked away with some great products, but also some good learning about what does and doesn’t work when doing discovery.
- Scope the brief
Discovery is an exciting time. But there's a danger the team can get carried away with all the potential directions a service could take. This can result in the discovery becoming unfocused, resource being spread too thinly, and the team not finding out enough to move forwards with the alpha.
You’re not conducting a discovery to solve the whole problem. You’re doing ‘just enough’ research to know what you should be testing in alpha. This means the discovery needs to have clear scope and boundaries. You might focus on certain organisations, certain parts of a process, or even certain geographic areas. Setting this focus may feel like you’re being restrictive, but in fact it means everyone can get sufficient depth of understand to learn the best place for your service to begin operating.
- Be clear on roles
There’s a lot of research in discovery, so people often think that all discovery research is user research. But that’s not true. Often there’s a lot of research around business processes or technical requirements.
User researchers are really good at asking questions and analysing information, but they are not domain experts. So while they may support research, for example by helping creating discussion guides or running analysis, they’re not best placed to lead the interviews in other domain areas.
Business processes are often best researched by business analysts and technical requirements by tech architects. You need to take time out at the start of your discovery to ensure that everyone in the team is clear on roles and accountabilities, and you have the requisite skills in the team.
- User Research as a team sport
User research is a team sport, even in discovery. On one level this means making sure everyone is involved in day to day research activities, such as attending interviews or participating in group analysis sessions. But this also means making sure everyone in your team feels ownership over the direction of the research.
User research that isn't integrated into the development of the product is wasted research. On data infrastructure, we run workshops where everyone in the team can suggest research questions that they want answered about their product. This helps make sure that user research is supporting the work of each member of the delivery team.
- User needs are important, but so are team needs
Discovery is exciting, but some people find it unsettling because it's such a rapidly moving period. So make sure you give your discovery structure. For example, use agile ceremonies like standups and sprint planning to set out and track discovery research.
A big mistake that often happens in discovery is that teams do not communicate their findings regularly - instead saving everything up for an end of discovery report. This can result in misunderstanding and missed opportunities as the whole team aren’t up to date with findings.
In Data Infrastructure we addressed this by creating user research playbacks. Every other week the team sit down for one hour and share findings from user research. It’s not about presenting a finished picture, but what we’re learning as we go.
- Document quickly to track your progress
Discovery can sometimes feel like you’re going round in circles as you try to get to the bottom of something. Often it feels that the team find and collect more data than they have time to analyse. This is normal.
To avoid this, it’s really important to document the progress you’re making. In data infrastructure we’re using a knowledge Kanban board that includes the columns ‘what we know’, ‘what we think we know’ and ‘what we don't know’. Things move from one column to the next as we discover more data about an area and are increasingly confident about our findings.
To make sure we actually have time to do the analysis, when we book in time for an interview, we book in time for the analysis as well.
- Use artefacts, but be happy to throw them away
'Artefact' is a fancy word for a thing that's being created. For example, an image summarising processes in a system. Discovery should involve a lot of mapping and conceptualising a problem space. Visual 'artefacts' such as user journey flows, or architecture diagrams are enormously useful for quickly articulating an area to other people. But don't get too caught up on them - they’re not valuable in and of themselves. Rather they are visual reminders for conversations. Think of them as prototypes for understanding.
- Get in the right mindset
Carrying out a discovery requires a certain mindset. Turning up with a "there's no point, we've tried this before" attitude or, just as dangerously, a "my solution is better than yours" mindset, is the kiss of death to the discovery process. You need to bring with you a curious mindset, open to the potential of doing something new, but while being mindful of the past.
- Manage your contacts
Discovery involves talking to a lot of people. This often means drawing on the personal networks of people in the team. In doing this there's a danger that team members don't coordinate with each other and hassle the same people for interviews. But, more worryingly, this risks creating an echo chamber where there isn't a sufficient diversity of research participants.
Make sure you use a simple contact management system and note who’s speaking to who. This doesn’t have to be fancy: we’re using Trello boards, for example.
So those are 8 lessons I learnt from our discoveries. I hope they help you as you develop your next amazing service!
Recent Comments