As a design leader, I have to do a lot more than sign-off pixel comps and consistency check builds and PRs. Some of the most important aspects of my role are providing guidance around processes and methods, helping teams find the right idea for the solution they are trying to build, and enabling them with new tools to achieve their goals.
This is the first part in a short series of articles in which I share the design process my team and I followed to take an existing product journey back to its core concept, through to prototyping, visualisation, and lastly development. The entire process (sans development; that was saved for our official sprint!) runs the course of little over three days of cumulative time; some solo working for myself and the other members of the team, and some collaborative time spent around whiteboards, hunched over notebooks, and gathered in meeting spaces to run through concepts and plans.
Thinking about processes, my approach is always ‘use whatever tool you need to get the job done’. I am an advocate for the ‘Lean UX’ method of product design; quickly reaching a ‘best’ solution through ideation, developing a prototype, and shipping something to be tested. There are also elements of design thinking which permeate the vast majority of the work I undertake; finding many solutions (quantity) and whittling them down over a course of iterations to find our workable solution (quality).
I recently read Jake Knapp’s book ‘Sprint’, which outlines the five-day GV design sprint process in great detail. I have repurposed some elements of this process — shortening where necessary and even dropping some stages entirely — to help move the team forward. Presenting a small number of ideas to the team, explaining them, and having team members vote on the one/s they believe to be worthy of carrying forward helped us reach the solution we have taken into prototype.
Process, for me, is something which is not fixed; I chop between activities and approaches depending on what I am designing, its context, and who it is for. There are hundreds of ways to approach a challenge and I like to believe that a distillation of many of the most popular methods have aided my delivery of a successful design and satisfied team.
Caveat: Product details have been omitted for the purpose of this case study, however the processes the team and I went through are described as accurately as possible.
“The beginning stages of redesigning your own work…”
The work we — the product team consisting of myself and a mid-weight designer, a front-end developer, and a slew of backend/service developers — were challenged to complete was an iteration of a previous journey step that had been designed, built, and ‘shipped’ (internally) some months earlier.
The journey as it stands is a mid-product critical milestone consisting of multiple discrete touchpoints which had been something of a challenge to design and build the first time around; we had definitely not worked to an MVP!
The request now was to address a small number of concerns:
- Iterate and re-establish the user’s journey for this point of the product
- To update the UI to match the evolved visual language that had been developed following the initial release of the product
- To update the tech stack to meet the standards the team were now working to: we had moved from a Knockout and MVC-based solution to React and CQRS
A modest challenge which needed to be completed in a single, two-week sprint (We work to Agile methods in my current company).
The first step of any new product design project is discovery: finding out as much as you can about the people using your product, their needs and goals, the business’ needs and goals, and any critical information that will steer the outcome of your product. We had an understanding of the ‘who’ and the ‘why’ but felt it a good idea to fully revisit and restate everything we had established.
For our user, we utilised a proto-persona based on what we knew of the end-user for this particular piece of real estate. To date we hadn’t interviewed any end-users directly but, thankfully, had steer from a customer representative, our business analyst/product owner, and customer liaison. Plus, some contextual and ethnographic research on Google helped paint a slightly fuller picture.
We restated our user’s goals, visibly, to help reinforce the journey we were iterating: having these goals visible to the team at all times gives a solid point of reference should anyone ever feel they’re ‘missing the point’ or are implementing something that might contradict the end we are trying to meet.
Once we had both of these fundamentals written up on the board, it was time to step into the user journey and rediscover what we knew about it.
“User journey mapping”
The goal for me at this point was to get into the nitty-gritty detail of the user journey as we had previously defined it. The flow consisted of multiple individual steps, various input types and requirements, and over fourteen individual data items which needed to be captured and referenced against a data source held within the same UI!
It was complex.
The journey had originally been driven by a technical journey to capture all of this data which itself was driven by the needs of a key stakeholder, not the customer, which is partly (only partly — the designer works with the material they have) responsible for the complexity of our original outcome. We as a team wanted to transform this journey into something more user-focussed, usable, and less technically dependent.
I mapped the journey out using a standard template format on our whiteboard: the template covers the touchpoints the user would need to use, the steps in the journey they would take, their emotions, and the challenges (and subsequent opportunities) that were present. The journey was also mapped with pre- and post- phases to identify additional actors and other external factors that might have an impact.
Once the mapping was complete, a few team members collaborated and exchanged thoughts on the critical points, questions and opportunities that we were aware of in the first iteration plus any new ideas and insights which came to light through the conversation. It’s the informality of these conversations that often yields the best results and avenues that might otherwise go unexplored. One point that came to light is that there was an additional journey within this part of the product which we had not considered…
To map this additional journey quickly, I turned to a shorthand method I’d used to map some other user flows.
The emphasis of this shorthand lies on what the user sees and what the user does (hence why we call it the see/do activity!) and is a very good way to drill down to the fundamentals of the touchpoints or elements that the user sees on their journey and the action which they need to take to progress or complete their goal.
This additional journey mapping task was a useful addition to our already-fleshed-out user journey. It highlighted where we may have been able to economise the users’ input and reduce the amount of time they would need to spend processing and reacting to information.
With proto-personas, user goals, and a user journey or two in hand we were able to look at how we might want to proceed with the next phases of our redesign process. We were already having conversations around how we might want to implement some revisions but without additional exploration into what we had already built, there was little point in trying to shoehorn iterations in.
Having the journey map and granular steps pre-mapped was a perfect opportunity to utilise a new technique I had discovered some months before but had never had a true opportunity to use; it was time for a Service Blueprinting workshop.
In the next article, I am going to delve into the service blueprinting session I ran for the team and the subsequent steps we took to get ourselves ready for redesigning a new solution for this complex, critical journey.