Lead Product Designer
Go to LinkedIn
Part 2. Maps and journeys
I read existing research, do my own research and watch research conducted by others. User flows and navigation are based on knowledge gleaned from the initial research and more research along the way. This means that having access to users or potential users is vital. No guessing games, please.
Begin with the end in mind: What is the outcome the user wants? If I know that, I can come up with new ways of helping them achieve their goal. So I start by finding out what job the user needs to do and the questions they are asking along the way.
My design process starts with the largest blocks and moves toward the details.
And here is a summary of the most important things Brad told me. As you read it, keep in mind that the advisor is in charge of the conversation at all times. That's one of the first things they learn. It's also something that most people, who have only experienced call centers from a customer's perspective, aren't aware of.
Brad felt that he was already adding value by telling clients about the many different ways of claiming Social Security benefits. But clients often objected to delaying their benefit claims because they didn't trust the system. Brad thought that if he could show clients their benefit amounts for each year, he could overcome that objection.
Other advisors had similar views, so that's the solution I ended up designing. It lead to many fruitful client conversations and a big jump in NPS scores for conversations around Social Security.
When I started working on a Social Security tool for financial advisors, I conducted a series of card sorting exercises. Based on the briefing I got from stakeholders and previous research, I phrased Social Security topics that can come up in client conversations. I then asked the advisors to lay out these topics in the order that they typically occurred and put aside less common topics.
On the right you can see the result from one of the advisors. His name was Brad.
Here's a list of advisor experiences that needed to be designed as part of the same Touchpoints project. The company's relationship with their customers was evolving and becoming more sophisticated. This project was part of supporting that transformation.
Here's an example of that. The first image shows channels that a financial services company can use to communicate with their clients. Some of these are subject to opening hours if contact centers aren't staffed around the clock. The red lines indicate different ways that customers and advisors can interact over the phone.
It also helps the team to get to know each other and to start identifying as team members.
And here are some of the benefits of conducting this exercise at an early stage, e.g. at the kickoff meeting.
When I was first introduced to this exercise, it was done on a whiteboard. But I soon learned that facilitating the exercise in a spreadsheet is a lot more practical, particularly when key stakeholders can't be in the room. Granted, Excel isn't very visually appealing. But it has the advantage of being ubiquitous and unintimidating to non-designers.
When I facilitate this exercise, I fill in the matrix with my own take first. Then I make a copy and delete most of what I've written. That's the copy that I send out with the meeting invite to all the stakeholders. Including examples in the matrix helps people understand the exercise better than any explanation.
Download double Know/Feel/Do spreadsheet
Download standard Know/Feel/Do spreadsheet
You might think that conducting the Know/Feel/Do exercise in a Google spreadsheet would be even better. I know I did, until I tried it. It got very chaotic, so I went back to Excel.
Know/Feel/Do for mediated experiences
Because I've been leading the creation of mediated customer experiences for the last couple of years, I usually create a double matrix. It includes both the mediator and the customer. In my case the mediator was a financial advisor helping customers on the phone or in an office.
In the double matrix I've added example entries to show how it can be used.
In case you're not familiar with it, the Know/Feel/Do exercise involves filling out a matrix for what the team wants the user to know, feel and do before, during and after the experience we're designing.
I like to conduct a Know/Feel/Do exercise with the team members at an early stage in the project. It pays to get as many stakeholders engaged as possible:
Once I know the basics of the project, I can start making decisions about pages and states. Here again I'm working my way from big boulders to little pebbles.
DIVIDE AND CONQUER
Download the whole sitemap
Since I moved to the Bay Area in 2008, I've mostly worked on transactional sites and apps. Often the interactions and data visualizations have been very complex. That's something I enjoy.
My goal when designing is usually that the user shouldn't have to focus on the interface. It should just do what they expect. There's absolutely room for positive surprises, but we all have better things to do than figuring out where to tap to make things go.
The purple thumbnail leads you to a deceptively simple user journey that I created back in the waning days of the waterfall era.
The purpose with this user flow was to give the team an overview of how the seller and buyer flows work together.
It starts out in a checkout flow that's detailed elsewhere. If we think the seller might be up to no good, we apply a hold to the transaction, as soon as the funds from the buyer come in. We also send an email to the potentially dodgy seller, telling them to ship the item that the buyer just paid for. The email is new, as you can tell from its pink color. It includes a link to a modified page (blue) where the seller can add tracking information to show good faith.
If the seller adds the tracking information, we send it on to the buyer. The email to the buyer contains a link to a page on which the buyer can tell us that they got the item. If they do that, we release the hold and the buyer receives payment for the item.
Note that I'm not trying to map out all possible flows. In fact, I'm omitting more than I'm including. It's important to keep user flows simple and uncluttered. Keeping things simple and uncluttered is always a good idea. Even more so for user flows, an abstraction that can be pretty difficult to understand for people who aren't used to them.
The wavy lines indicate that this is the flow as it appears to the users. It's not what happens behind the scenes. I leave the technical documentation to engineers and other technical staff, so I have time to design stuff.
On the other hand, I always create a flow. On the rare occassions in the past when I've tried to get by without one, there were always complications. Even if it's one page with two states, I jot it down as a flow. It's a very rare project indeed that stays that simple.
What were the objectives for this flow?
One task = one page
One of the first things I was taught when I started designing was that each page should correspond to a task. I still think it's a good starting point, but there are many exceptions to this rule. Here are a two:
One page = many tasks
When people use your app all day long, they would much rather do many different tasks in a row. Having to wait for a page to load between each task eats into their productivity.
An example of this could be a customer record in a CRM. The person working on the record will often need to change several values or launch several wizards from the record. It would be annoying if the user had to wait for a complete page refresh for each changed value.
One task = many pages
When the objective is to train people, it can help if each task is subdivided. That way your users really understand what they're doing. Once they've shown that they get it, all the subtasks can be grouped into a complete task. Later on when the user has mastered the whole task, they can perform multiple tasks at once, e.g. as macros.
Lessons learned in gamification
In gaming the learning process is formally addressed as part of onboarding. It's also used in gamified non-game contexts.
As an aside, I've taken a course in gamification of enterprise software and I'd love to put it into practice. There's so much more to gamification than leaderboards and cute badges. Millions of people spend many hours each day in enterprise software. That means that gamification and consumerification opens up many opportunities to improve users' quality of life.
When I first draw up the sitemap or user flow, I keep my options regarding pages and states open. I tell stakeholders that the boxes are topics or tasks and that I will define pages and states as we go along. If the development team thinks that the pages and states have been determined, they will often define them in the code as well. Then when scope and requirements change, they lead to expensive code changes. Part of the Agile methodology is to embrace change, so it's important to communicate clearly about what has been decided, and what's still on the table.
I also tell everybody that I'm showing them the flow as a basis for discussion. At this point everything is up for grabs, particularly if we can come up with solutions that move us closer to business or user goals. None of my deliverables are "my babies." If I advocate a specific solution, it's because it's better for the user, and by extension, better for the business.
PAGES AND STATES
If there is no existing polic to lean on, I start with research. This time it's quantitative:
Given the data, the product manager, engineering lead and I come to a decision about the number and placement of breakpoints. I would argue that in most cases fewer breakpoints are better. More important than the number of breakpoints, is that the user is in charge of how they see your content. That means not disabling pinch and zoom, accessibility selections, orientation locks etc.
Responsive design process
I then start designing for the most common form factor. I agree with the engineering lead on if I should sketch the layouts for different sizes as I go along, or leave it till the end.
My designs tend to have a strong information hierarchy, so often what the developers have done just needs to be refined. That's best done together. If any documentation of the decisions is needed, we take screenshots as we go along.
For responsiveness the design decisions boil down to:
Seeing that I just brought up responsive design, let's tackle non-desktop form factors next.
Responsive designs are relatively simple. In many cases, Product, UX and Engineering make a decision about breakpoints that apply to all projects. This decision is revisited a couple of times per year. There may also be ad-hoc additions if a new form factor surges onto the market, e.g. the recent iPhone X with its "interesting" notch at the top.
MADE IN PIXEL TOGETHER
As usual I included a legend. I usually weave in the legend as elements of the flow come up. E.g. the green page at the bottom is a manual step.
Clever stakeholders will see what I'm trying to achieve by looking at the legend. That's usually a good thing.
There were several things I wanted to highlight with this documentation:
Hand-off points between different apps. Advisors had to deal with a bewildering number of apps, all with different designs and interaction conventions. Again, making the hand-off points visible helped us minimize them.
Decision points and other "glue." The trainer for the advisors was going to be on the call. She needed to know how to train the advisors in using the tool.
This flow represents the experience of a financial advisor receiving an incoming call from a client.
INCOMING CALL FLOW FOR ADVISORS