Lead Product Designer

Cecilia Huster

Part 1. 

Before the design

Top down design process

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.


In the office there was a corridor with a whiteboard wall along it. So I was able to sketch and create lists to my heart's content. Having space for large scale thinking helps my process. Big spaces make for more and bigger ideas.

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. 

In the list on this whiteboard SF stands for Salesforce. PA was a proprietary system that was being phased out. SSB stands for Social Security Benefit. ACC was proprietary functionality. CIC was the phone system that the advisors used.

Armed with this list, I was able to move the conversation forward with the product managers and the designer in charge of creating the corresponding consumer facing experiences.

Early on in projects I like to work on a whiteboard. There's just nothing like it for quickly getting ideas down in front of me and exploring different options without opportunity cost.  

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. 

Team members: 

  • learn that design is about creating experiences
  • feel involved in setting direction for the project
  • become more focused on the user and/or customer
  • commit to creating an experience that serves both the business and the intended audience

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.

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. 

  • executive sponsors
  • subject matter experts
  • designers, writers and researchers
  • product owners and/or managers
  • development leads
  • Agile development team members
  • project managers and/or scrum masters


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: