--- title: Best practices for designing apps people actually use teaser: 'Making stuff is cool, but making stuff people actually use is amazing. Learn how to do the latter. ' tags: design,jobs-to-be-done,usability testing author: Devin Jameson published_on: 2020-02-21 --- ![A banner image that reads, "Best practices for designing apps people actually use" on the left side with an illustration of a phone on the right side. On the phone is a wireframe for a potential app with arrows indicating changes to be made.](https://images.thoughtbot.com/devinjameson-best-practices-for-designing-apps-people-actually-use/jPEbNB72QTOvcQBBpOj0_designing_products_banner.jpg) At thoughtbot, we pride ourselves not just on making products, but on making products people actually use. To accomplish this, we employ a [human-centric](https://vimeo.com/106505300) design process that embraces uncertainty and iteration. We know we don't have all the answers upfront, so we lean on our respective processes to illuminate the path to success. While each thoughtbotter's individual design process varies, each shares the same general trajectory. This ensures an approximate consistency of approach without stifling individual creativity or innovation. ## 1. Start by defining key jobs-to-be-done Coming up with solutions is exciting. So exciting, in fact, that one might forget to identify the problem! It's best practice first to step back and ask: "What problem is someone really trying to solve when they use my product?" In other words, what [job-to-be-done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done) is someone "hiring" my product to do? Generally, this actual job-to-be-done is not immediately clear. Consider the following examples of jobs-to-be-done that require some pondering to uncover: - Action: getting a snack from the kitchen - Possible job: satisfying one's hunger - **Actual job: taking a break from work** - Action: grabbing coffee before a morning train ride to work - Possible job: getting one's caffeine fix - **Actual job: passing time on the commute** - Action: renting a movie on Apple TV - Possible job: seeing the movie one wants to watch - **Actual job: relaxing with one's significant other** When you design your product to solve a surface-level job rather than a root job, you increase your odds of creating the wrong product. For example, if you identify your problem as, "People have trouble getting their caffeine fix on their morning commute", you may identify a caffeine pill as a potential solution. If the root problem is actually, "People get bored on their morning commute", a caffeine pill will not solve this problem. However, a portable gaming system or good book might. To create the right product, identify the root job-to-be-done before devising your solution. At this stage, you may want to conduct [User Research Interviews](https://thoughtbot.com/blog/tips-for-conducting-user-research-interviews) with potential customers, subject matter experts, or other product stakeholders. These interviews can help deepen your understanding of your prospective users' job-to-be-done. Here are some questions you might ask in User Research Interviews: - When you come across problem X, how do you solve it? - Tell me about how you came to use solution Y. What set of steps led you there? - Can you walk me through how you use solution Y to solve problem X? **Avoid** asking leading, closed-ended, or biased questions such as: - Would you use product X if it existed? - If you could use product X to solve problem Y, would you? - Tell me about how you would use product X if it existed. These kinds of questions, which bias interviewees toward particular answers, distort responses and produce bad data. They can lead you to believe you are designing something useful when you are not. Conversely, open-ended questions provide a window into how people think, and the insight derived from their responses can help you design a useful product. ## 2. Run a Product Design Sprint Now that you understand the root problem your product will solve, you're ready to run a Product Design Sprint. A Product Design Sprint is a process that enables people to quickly hone in on a product's potential features and create a prototype for user testing. [thoughtbot's Product Design Sprint guide](https://thoughtbot.com/product-design-sprint/guide) is an excellent resource for running your first sprint. It outlines the 6 phases of a design sprint, provides a recommended schedule for each phase, and links to a public Trello template you can use to organize your sprint. ## 3. Make a prototype Now that you've run your Product Design Sprint, it's time to make a prototype. Prototypes are useful for two reasons: - Usability tests require a prototype - Prototypes enable you to iterate on your design quickly The fidelity of your prototype should be based on your timeframe and the quality of interaction required to test your idea. I would recommend using either [Figma](https://www.figma.com/) or actual code. The primary benefit of a Figma prototype is that it's quick to produce and easy to update with each iteration. Alternatively, a prototype made in code (HTML & CSS, React, or whatever stack you're using) will take longer to produce, but will look and feel more like a real product and provide more realistic user interaction. ## 4. Conduct Usability Tests Prototype in hand, you now have the means to test your solution with real customers. [Usability Testing](https://thoughtbot.com/blog/practical-guide-to-user-testing) can help highlight the flaws in your design and uncover opportunities for improvement. The general flow of a Usability Test is to ask a user to accomplish a task with your product and take note of where they become stuck, confused, or frustrated. For example, imagine your product helps people find and buy tea. You may ask your subject to: 1. Find a tea they like 2. Add it to their cart 3. Submit their order Perhaps they struggle to find a tea they like, can't figure out how to navigate to their shopping cart, or have trouble working through the checkout flow. If so, great! You've just uncovered a flaw in your design that you can fix in your next round of iteration. ## 5. Iterate Now that you've uncovered the issues with your design through Usability Testing, you can iterate on your idea: - Did you misidentify your root job-to-be-done? Go back to step 1. - Think you're on to something, but need to re-think the user flow? Go back to step 2 and run another PDS. - Maybe your prototype needs a few tweaks? Go back to step 3. However you proceed from here, what matters is that you continue to increase your confidence in your solution with each iteration. No one has all the answers upfront, and anyone who pretends to is either naïve or lying. The process itself is the key to making products people use. It's worth mentioning that producing a high-quality digital product can cost up to six or seven figures. Best to make sure you're building the right thing before investing that kind of money. Have an idea for a digital product? Our experienced designers and developers would love to help you succeed. [Let's talk!](https://thoughtbot.com/hire-us)