Intro
Every project is different and you can’t too rigidly apply a process, but I have found that this broad approach works in most circumstances and is very flexible. I’ve outlined below this broad approach and who is involved at each stage.
Research
Most projects kick off with customer and competitor research unless we have existing research that we can leverage.
Early stage research is often at least partly interview based to dig into the problem space in detail and understand customer motivations, painpoints and opportunities. It can also include user testing and other research methods such as diary studies, card sorting and surveys.
Team involvement: at this early stage the work tends to be focused with researchers (or PMs or designers). When time allows it’s great to also get more team members involved in research to see the user problems firsthand.
Define
in the define stage I typically take the learnings from the research and:
Create or refine personas to help us keep our users front of mind (especially useful for ideation sessions);
Create or refine key customer jobs;
Map out key customer journeys with quotes and painpoints/points where drop off is likely;
Broadly prioritise based on key problems or jobs (and how they overlap with current business goals e.g. OKRs);
Figure out what we still don’t know and see how we could learn more (especially any quick wins).
Team involvement: I tend to report back on findings, then we prioritise problems as a team. I create or refine existing personas, jobs and map out customer journeys with some feedback from the PM. If it’s a new feature/business area I love to run team sessions to map out the customer journey so that we all represent different mental models/ways of navigating.
Design
The design phase typically covers an ideation stage, prioritisation (typically via RICE scoring) and a more in depth design phase in a design tool (Figma).
I usually run ideation sessions with a broad team from across the business (not just the product/dev team). We prioritise 2-3 problems based around key customer jobs, applied to a persona, and use a crazy 8s style session to come up with ideas. We tend to run a dot voting session to refine and group the ideas;
After ideation sessions we tend to have too many ideas and people tend to favour their own ideas so we usually do a RICE scoring exercise to have an objective view on prioritisation, and then choose a smaller number of ideas that score highly to further iterate and develop;
I then jump into Figma to refine the ideas and plot out the customer journey so we have a better idea of the experience to discuss as a team.
Team involvement: this stage is where a broader team is much closer to the problem and potential solutions. I may work on a small number of designs for a while to see how we can implement them in a user friendly way and plot out the customer journey, before we discuss them again to ensure the solution is feasible. I invite the team to take a look at designs as soon as there’s something to look at as their feedback is always valuable. At this stage I would also share with a larger design team if available for design focused feedback.
Prototype and test
Once we feel reasonably confident in our proposed solution we get it in front of users. With myself or a researcher running user testing sessions depending on timing/resources. At times I’ve also done very early stage guerrilla testing or tested with some colleagues around the office for reactions while still working on designs. The latter is just for initial feedback as colleagues don’t tend to be representative of users and are usually too close to the designs/business.
Team involvement: I tend to run our prototyping and user testing although I have worked with in house researchers at the BBC and at Monzo. At times developers have been involved in building coded prototypes when the design or testing need is more complex (e.g. our video player designs at the BBC once we were testing accessibility and subtitles). When possible I like to get the broader team involved with user testing but I always try to stay involved so there’s consistency across the results.
Iteration, refinement, build
In the flow chart above the design, prototype, test phase are a circle because there’s usually feedback from the research that needs to be incorporated (or even back to the drawing board completely). Areas that do test well are further refined as a team and turned into tickets for the developers to pick up. We then typically A/B test or MVT on our website/App environment to see how the design performs.
Team involvement: work with the team to refine design work, write up tickets, discuss build and assess the results of the testing and whether we should push the change to 100% or we need to remove or iterate again.