In week 1, we introduced two concepts, user experience and design thinking, both important factors in your product journey. One of the main points I highlighted was the ideology of building with the end user in mind.
I wanted to use this week as a chance to introduce another important framework, user-experience design, how it compares and differentiates from design thinking, and more importantly look to how that will help you shape and execute your user-centric product design lifecycle as you scale from idea to solution.
What is user-centered design?
Last week, I introduced design thinking which requires users to challenge assumptions, ask the right questions, and constantly redefine problems so that we can discover and drive solutions. However, user-centered design and design thinking are both intended to help find solutions to people’s problems, you may be wondering what the big differences between these two methodologies are. While the steps and general mindset of each are similar, the most notable difference is their primary focus.
User-centered design (UCD) can be best described as an approach to design that puts the user’s needs front and center and follows an iterative design process that focuses on the user’s needs every step of the way.
Now if you’re still scratching your head as to what the differences between the two are, let’s dive into it more:
To summarize it best, the goal of user-centered design is to focus on the user throughout the entire product lifecycle from ideation until release and be able to create an experience that reflects the user’s needs.
If you’re a visual person like me, here’s an example of how UCD is put into action with products and services we use every day.
While the main objective of YouTube is to watch and share videos, it also serves as a community where users are actively browsing through comments and suggested videos, all while simultaneously watching.
On the flipside, design thinking also requires great knowledge about the user. It also takes technological feasibility and business goals into consideration.
The design team at UberEats actively utilizes design thinking principles in how they look to drive user experience. A great example in how they achieve that is by implementing The Walkabout Program – where each quarter, their design team will go to a city where they learn more about transportation infrastructure, delivery best practices, and its local food culture to better understand how to deliver a superior experience for their app.
Product design lifecycle
Now that we’ve introduced UCD as well as highlighted the differences and similarities it has with design thinking, I want to put the emphasis on the process of combining these principles and putting them into action.
By following these guidelines, you and your product team will be better equipped to build a solution that aligns with each user’s needs.
Let’s take a moment to highlight each step and give best practices on how to put it into action.
Especially in an enterprise setting, the stakeholder often commissions a project to create a product to solve a perceived problem.
Think about this as your bottom line, the mission statement about your product. This statement should be understood and by all stakeholders (product, development, marketing, etc.), so that there is no grey area when it comes to what you are building, why you are building it, and who you are building it for.
“We do (X) for (Y) by doing (Z).” Thank me later, this will save you a lot of time when trying to concisely explain what it is that you are looking to accomplish.
Branding can play as big a role as user experience and functionality. The product must fit into an overall brand strategy. This can include what integrations are targeted to using the same typography and color palette.
Measure of success
This isn’t just for your designers, product or dev team. I can’t stress enough how important it is for you and all your stakeholders to create some sort of metric or barometer to reference when it comes to the optimal goal at hand. Measuring success can be subjective depending on the product or team. However, it should ultimately be fully aligned with your product vision/goals.
Determining which aspects of a product should be prioritized over others as it relates to the scope and project vision.
These are the “must-have” aspects of the product. These requirements help establish acceptance criteria later down the line in the process.
Making sense of the numbers. For example:
- How often are users competing tasks?
- How many users are running into the same issues during the onboarding process?
- How long does it take a user to complete a task or navigate end to end?
Obtaining and leveraging analytical data about users helps understand what they are doing.
Understanding the data users are utilizing during their tasks helps for user-defined acceptance criteria. In short, if specific types of data are used it’s important to understand this so you make sure to include that to show how the user interacts with the product.
For context, I used my own product I built last year called Swipabot, an automation checkout software.
We knew that our customers were mainly using it to purchase their favorite sneakers, so before we built anything we decided to ask some questions to gain insight as to what their “why” was.
A few of the questions included:
- Are you a manual user or do you use any type of automation software or alerts?
- How often do you purchase sneakers?
- What would be your preferred choice between a GUI or a CLI?
- What are some features you wish you had access to as it pertains to automation checkout software?
The best way to gauge any type of assumption is to create surveys to get quick responses to quantitative information.
Building blindly without testing is an easy way to run into issues once you are looking for feedback on your product. This can be done during the interviews but doing some sort of testing on each user’s existing products can help you improve your product and avoid the pitfalls the current software falls into.
The main point to emphasize during this part of the process is that there is no need to reinvent the wheel. Odds are there is an existing product or service that can help you improve your product when you are in the build stage, so you can improve on what others are currently doing.
These are often situational understandings of a particular user action. These can be best described as user stories and user personas.
User persona creation
A persona is a profile that contains the analysis of qualitative and quantitative information about a identified meta-person. Personas are made up of groups of real people who identify with a particular role. Each persona has its own goals, tasks, and motivations.
Using my Swipabot example:
Based on the 100 interviews we conducted, we set up two personas. I referred to them throughout the entire product development process.
Storyboards help you understand user stories in a visual way. They are created for specific situations or use cases.
Customer journey map
An experience map can help organize user stories in a logical way that allows product teams to build products quickly and efficiently.
Here’s an example from Swipabot using Miro:
Creating a workflow diagram or customer journey map allows you to conceptualize the end-to-end process as to how the user will interact with the product.
A site map visually shows the steps a user could take to navigate a product, this is analogous with information architecture.
Jotting down general ideas in a notebook or on a whiteboard is the free-form exercise designers can perform to get a general idea of concepts that could be used in the design of a product.
Once you have your sketches confirmed for the initial ideation, the next level up in fidelity would be creating wireframes. Wireframing takes into account the device constraints and dimensions on a whiteboard, or with a program like Figma, to create very low fidelity mockups for what a real design could mimic.
Using the wireframes as a basis, prototyping would be taking things a step further, where your goal as a designer is to create a “good enough” testable product.
Using the wireframes or prototypes, designers show users what they’ve come up with in a short amount of time. Users are able to physically interact with the product but no actual code or data is present. This instant feedback loop avoids expensive development effort to make sure when the product is built, very little changes would need to be made.
In order for us to get the most valuable insights about the user flow, we figured it was best to test by allowing a select group of users to simulate:
- Creating a task
- Creating a profile
- Adding billing and shipping information
From 20 insights that came from user testing, here were the top three:
- All users loved the initial home screen which is a dashboard that allows them to get a quick glance at their analytics
- Users enjoyed the ability to auto-fill information, so they don’t have to waste time
- Users said that they loved that the call-to-action buttons were visible
At this point your designs have been vetted and tested in the previous step. Here you will focus on delivering a hi-fidelity prototype which will typically have a bit more functionality than just your static low-fidelity prototype.
This is when your minimum viable product (MVP) gets deployed to a set of pilot users. The product should be thoroughly QA’d from both a design and development standpoint.
In the case of Swipabot, we were able to build a fully functional MVP in about eight weeks by using the MERN stack and Microsoft Azure to deploy our beta to a limited group of users.
Testing with the pilot user group, and beyond, if possible, should be a priority at this point. There is nothing worse than trying to scale a product when you have little to no feedback as to how to improve.
It’s showtime! User behavior should be closely monitored using analytics. Contact with users should be higher than usual to make sure the product is fully functional.
Again, the more you understand about how the user interacts with the product, the better!
Throughout this user-centric process there are multiple points at which the people who will use this product daily can interact with the product team. Following this iterative methodology allows stakeholders and users to be heavily involved in the beginning, during the strategy and discovery phases when building empathy and understanding is the focus.
Both user-centered design and design thinking are invaluable resources to keep in your designer’s toolbox. When choosing which design method will work best for your current project, it’s important to understand the subtle variance between user-centered design and design thinking.
While they share similar traits, overarching concepts, and fundamental principles, the small differences in their focus may make one method preferable to the other.
Most importantly, understanding each step and the subtasks within each step along these processes can power the success and growth of your product.
Now that you’ve learned about both UCD and design thinking, you’ll have some context when it comes time for you and your team to start brainstorming about your product lifecycle.
Looking ahead, next week on the slate we have Emphasize and Define, so be ready to take a deeper dive into your what, who, and how.
In the meantime, if you want to see how I put these concepts to use in their entirety, feel free to check out my portfolio for a full breakdown.
As always you can join me every Tuesday, on LinkedIn Live at 3pm EST and on Thursday on Twitter Spaces at 7pm EST, to ask me any questions or share anything you may have taken away from the blog post!
For more tips on prototyping and tools for bringing your product to market, sign up today for Microsoft for Startups Founders Hub.