{"id":284,"date":"2022-05-08T14:05:58","date_gmt":"2022-05-08T14:05:58","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/startups\/blog\/?p=284"},"modified":"2024-10-15T01:46:21","modified_gmt":"2024-10-15T09:46:21","slug":"zerotoone-product-design-lifecycle","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/startups\/blog\/zerotoone-product-design-lifecycle\/","title":{"rendered":"#ZeroToOne:\u200aProduct Design Lifecycle"},"content":{"rendered":"\n
In week 1, we introduced two concepts, user experience<\/strong> and design thinking<\/strong><\/a>, 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.<\/p>\n\n\n\n I wanted to use this week as a chance to introduce another important framework, user-experience design<\/strong>, how it compares and differentiates from design thinking<\/strong>, and more importantly look to how that will help you shape and execute your user-centric product design lifecycle<\/strong> as you scale from idea to solution.<\/p>\n\n\n\n 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\u2019s 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.<\/p>\n\n\n\n User-centered design (UCD) can be best described as an approach to design that puts the user\u2019s needs front and center and follows an iterative design process that focuses on the user\u2019s needs every step of the way.<\/strong><\/p>\n\n\n\n Now if you\u2019re still scratching your head as to what the differences between the two are, let\u2019s dive into it more:<\/p>\n\n\n\n <\/p>\n\n\n\n To summarize it best, the goal of user-centered design<\/strong> 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\u2019s needs.<\/p>\n\n\n\n If you\u2019re a visual person like me, here\u2019s an example of how UCD is put into action with products and services we use every day.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n On the flipside, design thinking also requires great knowledge about the user. It also takes technological feasibility and business goals into consideration.<\/p>\n\n\n\n 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<\/a> \u2013 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.<\/p>\n\n\n\n Now that we\u2019ve 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.<\/p>\n\n\n\n <\/p>\n\n\n\n By following these guidelines, you and your product team will be better equipped to build a solution that aligns with each user\u2019s needs.<\/p>\n\n\n\n Let\u2019s take a moment to highlight each step and give best practices on how to put it into action.<\/p>\n\n\n\n Especially in an enterprise setting, the stakeholder often commissions a project to create a product to solve a perceived problem.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n \u201cWe do (X) for (Y) by doing (Z).\u201d 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n This isn\u2019t just for your designers, product or dev team. I can\u2019t 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.<\/p>\n\n\n\n Determining which aspects of a product should be prioritized over others as it relates to the scope and project vision.<\/p>\n\n\n\n These are the \u201cmust-have\u201d aspects of the product. These requirements help establish acceptance criteria later down the line in the process.<\/p>\n\n\n\n Making sense of the numbers. For example:<\/p>\n\n\n\n Obtaining and leveraging analytical data about users helps understand what they are doing.<\/p>\n\n\n\n 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\u2019s important to understand this so you make sure to include that to show how the user interacts with the product.<\/p>\n\n\n\n For context, I used my own product I built last year called Swipabot, an automation checkout software.<\/p>\n\n\n\n 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 \u201cwhy<\/strong>\u201d was.<\/p>\n\n\n\n A few of the questions included:<\/p>\n\n\n\n The best way to gauge any type of assumption is to create surveys to get quick responses to quantitative information.<\/p>\n\n\n\n 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\u2019s existing products can help you improve your product and avoid the pitfalls the current software falls into.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n These are often situational understandings of a particular user action. These can be best described as user stories and user personas.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Using my Swipabot example:<\/p>\n\n\n\n Based on the 100 interviews we conducted, we set up two personas. I referred to them throughout the entire product development process.<\/p>\n\n\n\n <\/p>\n\n\n\n Storyboards help you understand user stories in a visual way. They are created for specific situations or use cases.<\/p>\n\n\n\n An experience map can help organize user stories in a logical way that allows product teams to build products quickly and efficiently.<\/p>\n\n\n\n Here\u2019s an example from Swipabot using Miro<\/a>:<\/p>\n\n\n\n <\/p>\n\n\n\n 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.<\/p>\n\n\n\n A site map visually shows the steps a user could take to navigate a product, this is analogous with information architecture.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Using the wireframes as a basis, prototyping would be taking things a step further, where your goal as a designer is to create a \u201cgood enough\u201d testable product.<\/p>\n\n\n\n Using the wireframes or prototypes, designers show users what they\u2019ve 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.<\/p>\n\n\n\n Swipabot example:<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n 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:<\/p>\n\n\n\n From 20 insights that came from user testing, here were the top three:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n This is when your minimum viable product (MVP) gets deployed to a set of pilot users. The product should be thoroughly QA\u2019d from both a design and development standpoint.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n It\u2019s 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.<\/p>\n\n\n\n Again, the more you understand about how the user interacts with the product, the better!<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Both user-centered design and design thinking are invaluable resources to keep in your designer\u2019s toolbox. When choosing which design method will work best for your current project, it\u2019s important to understand the subtle variance between user-centered design and design thinking.<\/p>\n\n\n\n While they share similar traits, overarching concepts, and fundamental principles, the small differences in their focus may make one method preferable to the other.<\/p>\n\n\n\n Most importantly, understanding each step and the subtasks within each step along these processes can power the success and growth of your product.<\/p>\n\n\n\n Now that you\u2019ve learned about both UCD and design thinking, you\u2019ll have some context when it comes time for you and your team to start brainstorming about your product lifecycle.<\/p>\n\n\n\n Looking ahead, next week on the slate we have Emphasize and Define<\/strong>, so be ready to take a deeper dive into your what<\/strong>, who<\/strong>, and how<\/strong>.<\/p>\n\n\n\n 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<\/a> for a full breakdown.<\/p>\n\n\n\n As always you can join me every Tuesday, on LinkedIn Live at 3pm EST<\/a> and on Thursday on Twitter Spaces at 7pm EST<\/a>, to ask me any questions or share anything you may have taken away from the blog post!<\/p>\n\n\n\n <\/p>\n\n\n\nWhat is user-centered design?<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
YouTube<\/h3>\n\n\n\n
Uber Eats<\/h3>\n\n\n\n
Product design lifecycle<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Strategy<\/h3>\n\n\n\n
Project vision\/goals<\/em><\/h4>\n\n\n\n
Brand strategy<\/em><\/h4>\n\n\n\n
Measure of success<\/em><\/h4>\n\n\n\n
Project priority<\/em><\/h4>\n\n\n\n
Discovery<\/h3>\n\n\n\n
Business requirements<\/em><\/h4>\n\n\n\n
Analytics review<\/em><\/h4>\n\n\n\n
\n
Content audit<\/em><\/h4>\n\n\n\n
User interviews<\/em><\/h4>\n\n\n\n
\n
Surveys<\/em><\/h4>\n\n\n\n
User testing<\/em><\/h4>\n\n\n\n
Analysis<\/h3>\n\n\n\n
Use cases<\/em><\/h4>\n\n\n\n
User persona creation<\/em><\/h4>\n\n\n\n
<\/figure>\n\n\n\n
Storyboards<\/em><\/h4>\n\n\n\n
Customer journey map<\/em><\/h4>\n\n\n\n
<\/figure>\n\n\n\n
Design<\/h3>\n\n\n\n
Sitemap<\/em><\/h4>\n\n\n\n
Sketching<\/em><\/h4>\n\n\n\n
Wireframing<\/em><\/h4>\n\n\n\n
Prototyping<\/em><\/h4>\n\n\n\n
User testing<\/em><\/h4>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
\n
\n
Production<\/h3>\n\n\n\n
Prototyping<\/em><\/h4>\n\n\n\n
Beta launch\/MVP<\/em><\/h4>\n\n\n\n
User testing<\/em><\/h4>\n\n\n\n
Release\/launch<\/em><\/h4>\n\n\n\n
User involvement<\/em><\/h4>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
What\u2019s next?<\/h2>\n\n\n\n
<\/figure>\n\n\n\n