HOW TO PRODUCT DESIGN PT. 2

This is the second part of a 3-part article.
Part 2 is a simplified research guide, written in a way that may be understandable by anyone at any point in their career or any level of expertise. I am not saying is a perfect formula or that it works for every research, the main goal here is to make you understand the foundations of research.

Imagine you are designing ‘X’ . Let’s call it X from now on.

Phase 1 — Research

1.1. The whole picture

• Make sense of the broader view
  How does X fit in the bigger picture of a Company, Department, etc;
  What is the size, level of complexity, or number of people/ teams/ areas it impacts

• Make a dependance list
  Is X dependant on other pages, tools, systems, etc.?
  What does that imply?
  

1.2. List the people you need to amaze & find how it would impact them

• Stakeholders
  Let’s assume for a minute that X is an App that will store personal data from/about your user. In this scenario the person responsible for data safety in the company will be one of the stakeholders.
  The Product Owner or Project Manager will ideally be the one to provide this information and will from the first moment be aware of all the requirements from all the stakeholders.

• Users
  …or End-users are the people that will actually interact with X.

• Clients / Consumers / Customers
  If X was a tool for a corporate internal use the users certainly will not be the same people as the clients of your business. This is something to take in consideration for evaluating priorities and impact beyond the tool itself.
  
  

1.3. As-Is Exploring

• Customer Journey
  Create a plausible story of usage of your product and map the touch points with your user and describe what is happening and how they are feeling.
  Let’s now imagine “X” is an online store. I’ll give you a minimalistic example of a customer journey:

• Competitive Analysis
  What are other brands/companies doing? What have they done that it’s good? Where could we do better?

• Service Map
  While the Customer Journey only maps and assesses the path your user takes, a Service Map also indicates the entire flow of the process(es) and with the different company teams/ departments/ physical spaces/ elements of structure of the architecture/ anything else that can be considered a touchpoint. In the same map you must identify pain points and opportunities.

• Pain points
  I always think the expression Pain Points is pretty self-explanatory: these are the moments of the entire journey that deeply hurt your user’s eyes or heart or brain. Or hurts the process itself.
  In which part, at which touchpoint, with which feature they just really start wanting to leave it all as it is and not reaching the expected end of the journey? What do they hate, what makes their tasks more complicated or time-consuming than they should, find out what annoys them, frustrates them, what makes them wanna quit their jobs and move to Tibet.

• In case there is already a version of X and you are designing X 2.0:
  Schedule a shadowing session to observe how they use the current version. Depending on the level of depth you are willing to go to there are a lot of approaches you can use to track different things: heat mapping software, eye tracking devices, diary journey documents, and a whole lot more.
  Besides shadowing, have a fluid conversation to listen in their own words what they love about it now, how they wish it would behave or perform, listen to their suggestions and let them dream BIG. After all, we’re aiming for greatness, even if for now we’ll just end up with something really good.

• Opportunities
  Where is there an opportunity for improvement? Adding or changing something that will ease a journey or make it more compelling? Or maybe is there some change that makes an entire process a lot easier like having your company subscribe a new service…
  
  

1.6. What are you looking to achieve & how to know you’re achieving it?

• Business goals
  You need to find answers for all the questions you can think of regarding the goals of X. Questions like these: What are the goals X means to achieve? Are they happening at what level? Executive? Operational? Other? Both? Does this project mean to increase sales revenue? To make a step of a process faster?

• KPIs — Performance Indicators
  At the same time we realize what goals are we moving towards we need to establish how we can measure the performance of whatever we end-up building in achieving those goals. These are called the KPIs — Key Performance Indicators.

Simplifying, this means we need to state which is the value that we are going to monitor in order to see if we have done a good job with our design, because if we did that value is going to be as high or as low as we wish it were.

Imagine X was a new Check-Out flow at an e-commerce website because the current version makes users drop the purchases. The immediate KPI that comes to mind is the number of purchases that are completed. Then it would be average time of completing all the steps of this new revamped feature. And so on.

Phase 2 — Statements

2.1. What-it-is and what-it-is-not list

Still on statements, another & final step to get you whole project completely defined is do a list indicating what X is and what X is not. This will be one of the most fast-enlightening parts of the documentation for anyone who is not you and is trying to understand what X is all about.

I would make this the final step also so it can work like a sanity check before moving on to more practical phases.

2.2. Requirements Definition

Based on the information you have collected in the previous phase, state everything that X should be able to achieve and perform:

it may be in a list or a table in excel, it can be in which form you prefer, just make sure that you have a source of truth to which you can always go for a reliable basis to work.

2.3. Jobs to be done + Feature match

“Jobs To Be Done (JTBD) is a revolutionary concept that guides you toward innovation and helps you move beyond the norm of only improving current solutions. A JTBD is not a product, service, or a specific solution; it’s the higher purpose for which customers buy products, services, and solutions.”

Do some deeper research on the JTBD concept and I 100% guarantee you will not regret it: it is a great way to state in more depth the concrete aims of whatever you are designing.

I would choose to do it in Excel so that you can them do a matching of features to each Job you stated. This can help you decide earlier what features do you need so that every existent feature or capability of X has a purpose — we already live in a world of overflowing information, choices and possibilities -, make sure your final product doesn’t get the user dizzy or lost but rather focused and on a smooth and well-flowing journey.

2.4. Bonus track: Dreams ft. Reality

What will deliver value faster? Where should you concentrate your effort first?

---

~ IN PRAISE OF DOCUMENTING ~

I know, all this research seems boring: and worse! It represents a much bigger slice of the project’s entire execution than we would like. Sometimes it can get very demoralising to having to spend so many days or weeks researching, performing so many interviews, doing so many lists & maps and spend less time building moodboards and sketching all the amazing ideas we have since we first heard of X. But trust me: this is the case where the hardest path is definitely the most rewarding. You will become a much better designer when you are able to juggle in your hands the constraints, the goals and the empathy.

So I’m guessing this may be a good point to remind ourselves that we make all these maps, lists, statements and definitions to feed our brain with enough insights and basis to be creative on the solutions we come up with and end up with beautiful, amazingly designed and disruptive products that actually make a difference in our users’ lives.

We also do this so we can keep everything documented and:

• Allowing anyone to go to it for information;

• Be an input in all-levels of decision making: you are reducing the risk of design something based on your own speculation and assumptions;

• Create empathy with the user — step in their shoes — almost become a user by empathising with theirs frustrations and wishes;

• Eventual spin-offs that might just end up being way more massive in terms of impact, one never knows;

• Smoothen the on-boarding of other people joining the project or in the event of them having to be responsible for it for some reason;

Find Part 3 of this article here.