Designing a Product Feature

Lily Li is a Product Design Manager at Abnormal. She has experience designing in the finance, healthcare, and education industries. Prior to Abnormal, Lily worked as a UX Mentor, Lead User Experience Designer, and Senior User Interface Designer. When she’s not working, Lily enjoys spending time with her family and drawing.

Lily Li: Hi, welcome to designing features that solve user problems as part of the fundamentals of product development. I'm Lily, I'm a Product Design Manager at Abnormal Security, and I'll be teaching this lesson. General topics I hope to go over today include: covering design process. How designers understand and define the problems. How we work with stakeholders, test with users, and the next steps. In the previous lesson, Maritza went over how to identify a customer problem and feel free to pause on the slides to redo the recap. And I'm gonna pick up from where she left off. 

Going over the design component, generally design is collaborative. However, the exact practice can vary from organization to organization. Some organizations there could be UX researcher, UX designer, UI designer, visual designer all working together, or some could be more end to end, like product design. In this lesson I will cover the process I would recommend for a small and agile team. Especially for people who want to start their own startups.

And there are different illustrations of the product development cycle out there. This is one variation that we created. So, generally, we start with uncovering and understanding the problem. So we define the problem, we ID the solution, design and iterate, and develop and test, and grow up, maintain. We kind of look back to this cycle. And there are different functions as a group of people working on this goal, and they can be roughly broken down to Product Management, Design, and Engineering. And as you can see, everyone here is involved throughout the process. At the beginning product management kind of leads the charge in helping to understand, define the problems. As certain organizations Design is heavily involved and then Design leads the charge in terms of adding the solution but both Product Management, Engineering are involved as well. And then during implementation Engineering cannot lead the charge in coding, building out the product and feature, while both Product Management, Design functions are involved as well. So if we just look back at this, if we look at the first three sections, it can be roughly defined as uncover the problem, define the problem and define solution. And it seems like a pretty linear path. However, there’s actually a lot of exploration going on. So maybe when we first started covering the problems, we realize there are a bunch of problems and we can pick one kind of narrow it down to the one that we want to solve. Similar with solutions; there could be a lot of different solutions. We can explore a bunch and then we narrow it down to one solution that we will start building out. And this is commonly known as the double diamond model in the Design community. And it was popularized by the British Design Council in 2005, where the first diamond it's about research and the second is design. There are other models as well, but they all convey a similar concept. And the two focuses of design are design the right things and design the things. This is just another rendering of the same diagram. 

And how do we understand, define the problem? So focusing on this component. As you can see, there's a lot of overlap with Product Management and Maritza already went over this section in her lesson so I'm gonna stay relatively high level. 

So how do designers do that? We conduct research by interviewing customers, going to observe customers, know our environment to understand their journey, their pain points. And we want to consider the experience for all the people involved and we create personas and a, I say, archetype and summarize a group of users that have shared journey and experience. Let me give a more concrete example here. Let's say we want to design an application for doctors who give physical exams. A doctor will be a persona potentially. There could be different types of doctors. Maybe there’d be specialists who will, say, give colonoscopy or other exams. But I just say there's a doctor group, but there's also nurses - could be a persona. Now nurses work with doctor and/or interact with application. Patients could be another one to consider. And maybe so doctor nurses and patients are so far role based. Personas are not necessarily role based. They're not market segments necessarily either, but just for an example, first time patients and returning patients could have different needs and the process of working with them could be different. So those could be broken out as different personas, for example. 

And then we have journeys for individual users or can create them for individual personas. So each of these data lines could be an event and an interaction with our service or application by access could go from, like, very unhappy to delighted. And with this line being more neutral. So as we can see: user can be very happy when this event happened, but maybe have some pain points of frustration at these two. If we interview a bunch of users… find that for this persona overall there's pain point at these points, those could be the target points for us to go focus on and target our problem, like, to define that as our problem to solve. And how we know if we design something that solved the problem. But if we solved the problem successfully, it should improve these users' experience, not only bringing back to neutral, but also delight them. So, this is what we call foundational research and focusing on this research diamond. 

And now let's shift our focus a little bit to talk about the designs. So how do we design with stakeholders? And I broke it down to ‘how do we prioritize?’ and the processes on ‘what we do’. So in this diagram, we'll be covering this area on how we prioritize. The way I see design is that the goal is to find the interest or product design, not design in general, but product design is still find intersection of business needs, user needs and engineering capabilities.

So here, I have a very simple example. I didn't wanna make things too complex. It's not quite a feature, but it's a small ask. Let's say the customer, we have a table that have five rows, and then they can talk to different pages. And we got feedback that customer wants to have imagination to be able to see 20 a page and be able to toggle to 20, 50, 100. And what we do is we ask the customer “why”? When we get a feature like this, where we ask the users, and let's say the user said, I need this just so I can control F and search for specific text in the table. This way I can find information much more quickly. And I only, I don't need to talk through as many pages. If that is the real problem, I will talk to multiple users and realize that it's something. A huge pain point for a lot of your users. And that's something we need to fix. Maybe another solution, instead of adding the imagination or in addition to it is to develop a better search. So maybe previously they had to click on the ‘filter by’ and see better field type in the information and hit search and see what they get. That takes a long time, that's why they want to search. Maybe in the new search, they can just start typing into the search and the table will shorten itself. So you can quickly narrow down to the result they want and they can change things. And this may provide an even better experience. So then they don't have to say show 100 a page and control F multiple pages. 

However, there's different costs associated with it. Let's say in order to do implement search that way, Engineering team has to restructure the table and the cost will be a lot higher. However, it does deliver an overall better experience for the long term, and potentially rewriting the table can provide other functionalities as well. So the constant impact of both high imagination can solve user problems as well. Even though there could be limited impact, like the cost is also lower, so which one would be right? And that just, that depends on the business needs, and each individual user needs and how soon we need the feature delivered is not - there isn't necessarily one answer is always better. So it just depends on the situation. And those are just examples of how we think through things and prioritize and work with PMs and Engineering to figure out what solution we will go with

And in terms of the process - design process. So we usually go from rough workflow, high level to higher fidelity mockups or here, like higher fidelity means like more details, to like interactive prototypes. Let me give a couple examples. You use an example of a user or two user workflows where a user may come into the application login and then do multiple things and then might lead to different results. Sketching out these kind of diagrams can help us visualize the user experience and account for different scenarios that we may otherwise miss. And then also make conversation with other stakeholders easier. And there are various tools that we can use to create these kind of diagrams.

And there are just a couple listed, there are many more out there. And once we have a diagram like this, we can flush out the screens. Obviously these are the steps. Those are good general practice for designing features zero one. But if let's say we're redesigning a button for a specific. Page, we may not need to create a workflow so just caveat that a little bit.

And for example, we have login screen. We can create wireframe for the screen. So wireframes are just like sketch out version of the interface. There's low fidelity, less detailed, high fidelity, more detailed. A couple examples, low fidelity wireframe can look like any of these. There's not necessarily a right way to do it.The general commonality is just it's quick to sketch out and we don't have to provide all the information we have to fill in the data. It can just– This could be representation of text, for example, this is quick draw out. The font, color do not matter as much. And this is saying that going from this to that screen, there are probably each individual gray box here is probably a card of some kind with more detail in there, but the focus is more on this flow.So that's where the co-op is. Whereas when we move to the higher fidelity. We'll have the play more close to the interface that we actually want to develop. So again, some tools here commonly used right now are Figma to BXT, in the field. And when we develop the high fidelity wireframe, it's good to leverage a design system. Design system takes some time to create but it can save time in the long run. So what is a design system? It's– in a way it's like a library where we put information on what we want each element to look like. So we have a standard. Here we have text, like for headers, we always want it to be this size with this color, with this amount of spacing around it. For body, we have another variation colors. If we want to call a specific type of red, it will always be that shade. And we know how many, how much freedom we have with colors, even down to spacing opacity.

Another thing to consider while we design is accessibility. It's easier to design interface with enough contrast, for example, as we were mocking the screens then design it, handed to engineer and then do test and then realize, oh, maybe we need to change all the colors because let's say we have this is super light gray and this as difficult to read. So it's easy to do that sooner than later. This is, this can be a whole course in itself, accessibility as well. 

But back to the general process. Sometimes we also create interactive prototypes, especially if there is a more complex flow. So this is one example of doing it in Figma where we say once a user click on this button, then link it to that page. Or when user present this, then show a model. Interact prototype can also be built through HTML, but generally it's before Engineering, like, pulling real data and build the backend database, et cetera. 

So why do we work through increasing complexity? And why do we go iterate through these different versions?

One is to save time so we can iterate fast and iterate early. Another is to focus the discussions. So when we're looking at say a low fidelity wireframe, just brainstorming different ways to solve the problem. We don't have to derail the conversation by talking about copy, text on the page or this shade of blue doesn't work, as well as that teal color. And again, these are just general process. We don't– for each project, we don't have to go through every single step. A few other things that we consider as we were design, as we're designing are following general heuristics. So a lot of these, this is one set of example of Jakob's heuristics that's published in on the Neilsen and Norman website. There’s the link, and there are other heuristics, for example, I think Norman has another set, but they're generally based on human psychology based on how humans interact with computers or machines. And just grabbing one of them as an example, to keep in mind as we design visibility of system status. So if we are designing something, let's say users submit a form and then it will take 10 seconds to see the results. It may be good to show indicators that the system is processing. If we're designing something that maybe take 30 seconds to load again, showing the indicators and potentially we can show like a quote while user waiting. So basically taking into consideration of user's needs. Some others are like recognition rather than recall. So if we can leave, let's say we do a search. If we can leave the search term in the search bar, show the search term when the result returns, that's better than just wiping the search term. And just show a bunch of results. 

Another thing we do to ensure the quality of our design. So we're not designing just for output, having power, many wirefirms or designing for outcome, to improve user experience. In order to do that we also sync with other designers. And this is an example here of asynchronous critique, where we critique each other's work, asking questions, giving suggestions. We also can do synchronous critique at the same time where people can come in and say, I want feedback on visual and feedback on flow, et cetera, and others can give suggestions.

More importantly, we can test with users and iterate through that. So earlier we talked about foundational research and design the right things and collaboration with PM, Engineering. And here I'm more talking about usability research. So once we have defined the problem, we have a solution in mind, we're going to test with users before we deliver this solution. Where before we ask engineering to start coding that solution.

And an example of use of lead testing. Again, very small example. Let's say we design a screen that we're a, we're adding a deleting functionality to a screen. And we asked users to use that interactive prototype. We just developed earlier and ask them if you were to use this screen to delete John Smith, how would you do it?

And let's say we talked to five people. The first person said, I would write click here. That didn't work. Let me try something else. And then we talk, all of them will basically say click on the row. I will. I expect to do it through clicking here, clicking on the record. And our original design actually had us having an edit elsewhere where you click on the edit to enable editing and edit it through a different screen.So then through the user usability testing will find, okay, the origin design is not intuitive, so we should tweak the design so users don't have to learn this thing that could be missed when they actually want to use it. And the benefit of doing that is that we can iterate and improve the design before Engineering start coding and save time and money for the company. And say before users start using something right. That doesn't work. So it's safe, reduce frustration for our users. 

So let's say we designed the pages, passive users, improved and iterated on the design. Then we would hand it off to Engineers. I don't like to call handout because Engineers will be involved throughout the process, giving feedback and designing with us. But generally it's still helpful to have annotated design to say, okay, maybe this one is a stretch. And make sure you make changes to this area cause that it's hard to see, but it's the existing area. So have some kind of call out on the changes that could easily be missed or there could be other scenarios and walk through the changes with the Engineer. Minimize the amount of misunderstanding that may happen. And after development which provide who is gonna cover that area, design will also work with Engineering team and as some more Engineer Quality Assurance team as well. So working with engineering QA to test before it go out to make sure everything is, as the team had envisioned. And after release, if there are metrics set, how would find that? How we define success or how we follow up or check the metrics and follow up with customers for feedback. Remember when we first talk about the goal of designing a lot of these functions is to– or features designing a lot of these features is to improve people's lives and reduce the pain points and frustrations. So did the product redesign improve user's lives?

And based on the learnings from these conversations with users, we can iterate and go through to basically identify new problems. We can go through this cycle again. And sometimes when we develop software, we have this grand vision in mind of what it will look like if we were to solve all the problems, but we can't necessarily design or implement that right away. So we break it down to crawl, walk, run, which Maritza covered. So sometimes we may have developed the crawl version and based on customer feedback, we figure out there are other things we can pivot. We can do that in addition to what we want to add onto the walk phase and kind of move the application where the product to the next phase and moving toward that north star. 

To recap, design is collaborative. It's about solving the right problem. The right way. Design is iterative and testing prototype with users can improve the quality of design and we want to ensure the outcome and not just output of the design work. 

That's all I have prepared for today. Thank you again. I hope you enjoyed the Product Design component of this course, and I hope the information was helpful. Bye!