“How do you tackle a project?” is a question I am asked on a regular basis. I could document my process as a formal presentation and set it out here as “The Way” I work, only the reality is more nuanced than that. Over the past twenty-odd years I’ve amassed a huge collection of tools, techniques and approaches to solving difficult problems, designing multi-channel solutions and winning the hearts and minds of stakeholders.
What follows is a case study that should help to answer that question. The project isn’t a real one, but the approach and assets are the kind of things that you could expect for your project.
Setting the scene
A few years ago I did some work with a healthcare company looking at consolidating a dozen offices into one shared service centre. While there was a lot of focus on the people who were cared for those and who did the caring, one stakeholder group wasn’t in our immediate plans: the relatives. We’d pushed them to one side (for the moment at least) simply because the technology we were planning on using came with a “relative’s portal”. Yet for a relative having a stranger walk into mum or dad’s home is a nerve racking thing. Someone they do not know is suddenly responsible for making sure mum’s taken her medicine, preparing meals for dad or even showering your otherwise vulnerable parents.
This generates a lot of anxiety that a passive portal doesn’t help with. I decided to explore whether a mobile app could be used to help build confidence in a relative’s care and reduce their anxiety.
I set aside a couple of days for this project. It isn’t a fully thought out solution and there are plenty of things missing, details that aren’t fully fleshed out and assumptions that have been made. As you read through please remember this is intended to document my process, not present a completed client engagement.
Understanding the problem
Great products solve a person’s problem. They make the customer’s life easier in some way to such an extent that they become an intrinsic part of their lifestyle.
My first responsibility on a project is to understand what the problem is. Sometimes that means taking a well thought out business case or brief and running with it, othertimes I have to create the business case. Whatever is required, my aim is to work with the various stakeholders to get a clear definition of what the problem is we’re trying to solve, what success looks like and what constraints are in play as well. This becomes the project brief.
The initial problem statement for the project. Typically these statements come to me as a problem the business has to solve.
How the brief is communicated depends on the organisation I’m working with. Some prefer formal, PRINCE2 style “Project Initiation Documents”, while others use a simplified “Project Charter”. My preference is to use a simple persona based structure that captures the essence of what we’re trying to achieve as a team. However, this isn’t only about the customer as the business will have objectives as well. These must also be captured and used to help direct the work.
Turning the problem statement around to become a customer-centric one.
Next comes data. Whether it comes from surveys, reports, emails or one-on-one interviews I build up a knowledgebase of data that will inform the work to come. Generally I’ll have some ideas about what I need to know, which I set out in a “key facts” document and use to guide my research and provide “traceability” for the data that underpins the design. If there are gaps in what I know I can either structure a research brief for surveying work or interviews, or assumptions can be made. Making assumptions is fine, provided the project team knows what they are, are being open about them, keeping track of which ones have been made and putting in place something to test and validate them during the process.
A knowledgebase sets out what I need to know, then fills in the gaps.
As the knowledgebase grows I start structuring it. Data is turned into statements that I can then cluster, prioritise and explore. Ideally this is where a workshop takes place, drawing on the team’s collective knowledge to start agreeing where priorities are and what needs to be done to close any gaps. If a workshop isn’t possible (and some organisations do not take to them) then I’ll work alone and validate my findings with the team. Ideally this is where my post-it notes make their first appearance, although I have been known to use Keynote to carry out card sorting exercises where there isn’t the wall space available.
Brainstorming helps to structure the knowledge that’s been built up. Here a Keynote based brainstorm has begun to structure the various facts about why relatives call and their potential emotional states.
Structure the customer’s experience
To gain a wider understanding of the problem domain and how the solution might fit into it I use the data to create an “as-is” Customer Experience Map. This shows the customer’s current thought processes, their actions and potential emotional states, as well as the touchpoints they have with the business and the supporting functions.
As the map is created pain points and opportunities to do new things will emerge, as well as things that the business needed to do to make it all happen. These new requirements are captured and used to create the “to-be” Customer Experience Map, which becomes the foundation of the design.
An experience map shows what the customer does, what they’re thinking and how they feel. This is the “to-be” map, helping keep focus on what needs to be developed as more detailed design takes place.
Creating these is a highly iterative process. I’ll usually create the initial designs during workshops or meetings, then work with stakeholders to refine them further before a final “present back” and validation session. The validation session is particularly important for the to-be map as this creates our requirements for the project. I’ll typically capture these in a “product backlog” as user stories and work with my client to prioritise and validate them.
Create the journey
A user journey links the overarching customer’s experience into a specific user experience design. My focus now narrows onto the chosen solution and channel and the design starts to take shape. There are a number of different approaches I use at this stage, from creating formal process flows (usually best for complex, rules heavy journeys with lots of links to other processes and data sources) to lighter storyboards. I’ll also start to build up an information architecture, showing how elements in the user experience link together and the data that drives the solution. It’s also at this stage that I’ll introduce behavioural design elements, particularly if the solution requires the customer to adopt new behaviours or form new habits.
A 4 part storyboard shows how a user might experience the app. These help to get a sense of how the solution might work and the environment in which the user operates.
For each required scenario a user journey is created, showing the screens the customer would typically move through and what their main purpose is.
Whatever approach I take it is important to ensure the team understand and buy into the design. Workshops work well to top and tail this phase of the design, although one-on-one and design pair sessions also have their place.
Building the prototypes
From the journey I start to build the wireframes that describe how the solution should work. Low-res wireframes are where I start, allowing me to quickly create and validate individual elements within the user’s experience. I can ensure the right elements are being presented to users, the right data is being captured and the flow and presentation is appropriate for the user’s needs.
Annotated wireframes show how specific design elements are intended to work. When I use Keynote to create these I’ll often link them together into low-res prototypes to start getting a sense of how the experience might work.
To give the wireframes context and life I’ll also start linking them together into an initial interactive prototype. Although the interaction won’t include entering data, the team will be able to start playing with it. Where the solution is supporting a non-digital channel (such as in a contact centre or face-to-face in a branch) I’ll use role playing, based on transcripts from call recordings or interactions with real customers, to validate the design. All of this learning is fed into the next iteration of the design.
Exploring different options within the UX. In this case I wanted to test my original “task list” design against a more contemporary “card” based one.
Higher resolution designs start to create a sense of how the solution will look and feel. My preference at this stage is to use real, albeit not perfect, text and images to bring the design to life.
Project teams can become a little “blind” to the failings in their own work and so I prefer to involve outsiders during the design process. Whether these people are real potential users or limited to internal staff acting the part is a client decision, although I will always advocate the former. To create a sense of reality for these volunteers I’ll create a higher quality prototype that they can interact with and explore. Although it might be created using Keynote and lack some functionality, my aim is always to put something in front of the volunteer that at least looks like it could be a real system. This makes it easier for people to relate to the prototype and provide honest feedback on what they think is missing or could be better.
If you’d like to have a play with the prototype I built for this project you’ll find it here.
Testing the prototype involves trying to recreate real-world situations where it might be used (including sitting in front of the TV and trying to concentrate on two things at once).
The documented solution
By the end of the design phase I expect to have:
- an agreed customer journey map setting out how the solution is supposed to flow;
- annotated wireframes that describe each element in the UX design;
- an information architecture that incorporates any site maps and entity relationship diagrams; and
- a product backlog of user stories that set out the functional and design requirements for the solution.
Not only does this help other members of the team understand what’s supposed to be built, it also provides future project teams with something to work with if a decision is made to extend or replace the solution in the years to come, and it provides management with a point at which they can approve further work (if that’s what they require).
For me “Agile” means being able to take new learning, requirements or insight and be able to include it in the design as we go in a structured way. My approach is geared towards this, which means I can take a new requirement, assess it against the design for its impact, feasibility and practicality and incorporate it (or park it) quickly and thoroughly. For some clients this has involved working in a highly iterative style, others prefer something more linear yet equally flexible. What’s important is matching my approach to my client’s need and still retaining flexibility to adapt as requirements do.
Where from here?
Putting this mini-project together took a couple of days and is far from complete. The projects I work on typically last for several months and involve a lot of analysis, hard thinking and detail. That said, I have run highly focused projects that have attacked just a single issue in just a few days. The key things I want to remind you of is that my approach is focused on meeting the needs of the customer in a way that the business can support, building buy-in with stakeholders and validating designs by using prototypes to test assumptions and solutions.