beginners_guide_to_designing_apps_and_interfaces_1_0
0 likes259 views
This document provides an overview of a 4-step user-centered design process for creating apps and interfaces. The steps are: 1) Define the problem by understanding user needs through observation and interviews; 2) Prototype solutions quickly through paper prototypes and storyboards to get early feedback; 3) Evaluate designs using usability heuristics; and 4) Learn and iterate based on user testing to continually improve the design. The goal is to help readers with little design experience go through a process that will result in designs focused on solving users' problems.
beginners_guide_to_designing_apps_and_interfaces_1_0
- 1. A Beginner’s Guide to Designing Awesome, User- Centered Apps & Interfaces by jesse flores
- 2. Introduction! 3 Overview of the Process Define the Problem! 7 Solve One Problem Well How to Identify the Right Problem Prototype Solutions! 17 Create a Design Brief Storyboard Paper Prototype Digital Mockups Evaluate the Design! 27 Usability Heuristics Learn and Iterate! 32 Conclusion! 36 Learn More about Cognite Labs tweet this! ! ! 2
- 3. Introduction Take a second and think about something. When was the last time you tried to push a door open when you should have pulled it? Or struggled to figure out how to change a setting on an appliance or in your car? Or, fired up a software application to get some work done and spent way too much time trying to figure out how to change some setting you couldn’t find? How did those experiences make you feel? If you’re like most of us, frustrated. Now, think about how your customers feel when they come to your site. Can they find the products or information they want quickly and easily? Is what they need to do intuitive? Or are your users pushing when they should be pulling? Good design brings us joy. It helps us to solve important problems and get more done. When we find a well designed product, we embrace it, we share it with others, and the product becomes indispensable. tweet this! ! ! 3 Good design brings us joy.
- 4. So what does this have to do with you and your business? That depends. If you don’t care about your customers’ experiences, if how they interact with your site doesn’t matter to you, and if your coffers are bursting at the seams with no end in sight...nothing. Otherwise, this book will help you to think about your site a little bit differently and offer some guidance to help make your customers’ lives a little bit easier, a little more productive, and a little more delightful. In return, they’ll reward you with increased revenues, brand loyalty, and even brand evangelism. What’s more, while these tactics are intended to focus on web design and development, the principles extend to other facets of your business as well. So, hopefully, you’ll also get some ideas on how to speed up innovation all around. In the following pages, we will introduce you to a 4-step design process that you can use when creating a new application or evaluating an existing one. It’s intended for readers who have little or no formal experience with application or interface design and are looking for something that can provide an overview that’s both brief, and actionable. So, let’s get started. tweet this! ! ! 4
- 5. Overview of the Process Great design moves us. We attribute genius to designers who produce great products. And often deservedly so. But, like many things, anyone can achieve competency with a little practice and a good process. You may not be Jony Ive, but you can still produce great products for your users with the right set of tools. A basic design process has just four steps: 1. Define the Problem. Great design is fundamentally about solving problems for your users well. It’s the necessary starting point. 2. Prototype Solutions. If you have to get ‘the right answer’ right away, you might want to switch careers. Design is messy and you’ll likely not ‘get it right’ the first time. It’s ok. 3. Evaluate the Design. There are objective criteria you can employ to help you evaluate the merits of different design choices. We’ll introduce you to some. 4. Learn and Iterate. Design is never ‘done.’ Users behave in unexpected ways, circumstances change, some elements will perform better than others. Learning and iterating keeps your design fresh and relevant. tweet this! ! ! 5 Anyone can learn to design well with a little practice and a good process.
- 6. That’s it. Just a few steps to keep in mind and you’re on the way to making something great for your customers and users! In the following chapters, we’ll expound on these ideas in more detail and provide you some practical tips you can use to get started today. tweet this! ! ! 6
- 7. Define the Problem What problem are you solving for your users? While this might seem like an odd question, the answer to it lays the foundation for design. If users are coming to your site, it’s because they’re trying to solve some problem, to accomplish some task. Clarity about that problem is essential to solving it well. For example, why do people use Facebook? Because they want to stay connected to people they care about. So, Facebook is designed to facilitate that with newsfeeds, timelines, and the prioritization of content. Why do people shop on Amazon? Because they have tons of products that can be delivered at a relatively low cost. So, Amazon has a powerful search engine and well-organized catalog. They even built a recommendation engine to help you find products you might need, even if you hadn’t made the intention explicit yet. Good design is ultimately about solving a problem for your users well. So, it stands to reason, that you should have an idea about what the problem is before you embark on the design process. tweet this! ! ! 7
- 8. Solve One Problem Well Unless you’ve already grown like gang-busters and what’s keeping you up at night is fulfilling the overwhelming demand for your product, chances are you haven’t yet clearly found the right problem to solve. And that’s ok. Defining a problem is hard. But it also means you should seek clarity before you invest too much time or money in further application development. I can hear it now, “We’re solving problem x and y and z and...” No. Especially at an early stage, it’s important to focus on one problem and make sure it’s being solved well. Then, once you’ve got a pattern of growth and significant revenues, can you consider turning your attention to other problems. By the way, many really successful companies never deviate from solving their one problem well. They just get better and better at solving that single problem until they’re the best solution for the problem. So, how do you choose which problem to solve? Or, how do you know if you’re solving the right problem? You test it. tweet this! ! ! 8 Focus on one problem and make sure you solve it well.
- 9. How to Identify the Right Problem Because good design and the success of your product hinges on solving one problem well, it is important to identify the right problem. So, how do you do that? It starts with good hypothesis. Generate Problem Statement Hypotheses Now comes an exercise. Get out some sticky notes and a Sharpie. We’ll wait. Got them? Good. Now, with your co-founder, partner, a team member, or by yourself (as a last resort; 2+ heads really are better!), write as many one-sentence problem statements as you can that describe the universe of problems you intend to solve. Use real sentences, visualize a specific user, and identify the benefit you’re providing that user. For example, “a better invoicing tool” is a poor problem statement because it’s too product focused, doesn’t describe a user (‘better tool for whom?’), let alone the benefit to the user, and “better” is an ambiguous term. “An invoicing tool that sends email confirmations” is also a poor statement because it presupposes you know that email matters or that invoicing is where the problem lies. A better problem statement would be “helping small business owners with little accounting knowledge track their receivables.” This could be a relevant problem and solved in myriad ways (just ask Freshbooks or Quickbooks). tweet this! ! ! 9
- 10. Set a goal (we suggest 25) for the number of statements you’re going to generate, and set a fixed amount of time for the exercise (we suggest 30-45 minutes). Try to maximize both; that is take full advantage of the time and write as many statements as you can. The goal should be the minimum number of statements articulated in that timeframe. “Wait, you just said, I get one problem,” I can hear you saying. True. But, remember, right now we’re trying to determine what the problem is. And chances are, your first attempt will need refining. By creating a list of potential problem statements, we’ll make it easier to determine which problem is the right one to solve. Nobody likes being told their baby is ugly. But we all know there are ugly babies. Identifying several problem statements makes it easier to approach hypothesis testing dispassionately. It becomes easier to compare candidate hypotheses against each other and test which statements matter most. Liberating the emotional element and framing tests as a competition will allow you to go further, faster. tweet this! ! ! 10 Good Problem Statements: •Identify a specific user •Articulate the benefit the user derives •Use unambiguous terms Poor Problem Statements: •Presuppose the answer •Aren’t targeted towards a specific user •Are product, not problem centered •Use ambiguous terms
- 11. Test Hypotheses Once you’ve generated your problem statement hypothesis, it’s time to test them. There are many ways to do this, but we’ll offer two: observation and user interviews. Observation The design firm IDEO is famous for making awesome products. They designed the first mouse, the first laptop, and a slue of other cool things. And the source of much of their design inspiration? Observation. In The Art of Innovation, Tom Kelley emphasizes paying attention to how people interact with the products around them. He describes how observing areas where people struggle, asking ‘dumb’ questions that both empathize with users and give them the benefit of the doubt, and gathering many, different types of perspectives and interactions helps the firm to clarify problem statements and design great products. The same process can be applied to software applications. At this point, you should have generated several hypothetical problem statements. Now, go out and see if you can find people trying to solve one of those problems. What tools do they use? How are they interacting with those tools? Where are they struggling? Do they know if they’re struggling? Do they care? tweet this! ! ! 11
- 12. Taking time to observe real people attempting to solve the problem does a few things. First, it allows you to validate the problem exists. For instance, if you’ve defined a potential problem as “helping small business owners with little accounting knowledge track receivables,” but can’t find a small business owner struggling to track their receivables, you might be focused on the wrong problem. Observation also allows you to pit one problem statement against the other. If it’s not clear your potential user is struggling to track receivables, maybe it is clear they’re struggling to manage expenses. By having a few problem statements at the ready, you might not see the initial problem you expected to, but you may see one of the other problems you’ve articulated. The problem you see occur most frequently is likely the one worth solving. Finally, observation allows you to empathize with your users. When you take the time to see the world from their perspective, it becomes easier for you to design a product they’ll love to use. Observation allows you to account for the subtle quirks and annoyances that frustrate users and take up their valuable time. Watching them solve the problem will help you to avoid these pitfalls. Observation can be especially great if you already have a working product. Chances are you’re monitoring web metrics, which tells you what they’re doing, but not why or how they feel about the product. By selecting tweet this! ! ! 12
- 13. some of your users to observe, you can learn a lot about their experience, which can help you refine the product, prioritize features, and make sure you’re delivering them the best possible value. User Interviews Another great way to determine if you’re solving the right problem is to conduct user interviews. If you already have a product, then this is an indispensable tactic and should be employed regularly. Different from observation, conducting user interviews opens the door for a conversation about not just what users are doing, but why they’re doing the things they’re doing. It also allows you to capture the words your users use to describe the problems they’re experiencing, so that you can frame your product to meet their needs. One of the first choices you’ll have to make is deciding who to interview. Of course, you want to interview a diverse set of your ‘typical’ users. Or, if you don’t have users yet, folks who you think might be typical users or who are typical users of a similar system. You should also consider interviewing extreme users; folks who use your product (or a similar one) way more than the average Joe. Talking to those folks might give you some tweet this! ! ! 13 Who to Interview: • Typical Users • Extreme Users • Non-Users •Stakeholders
- 14. ideas for habits they’ve formed or tricks they’ve picked up and might reveal design insights that could delight your typical users. Another group of folks you might want to interview are non-users of your system, particularly if those non- users exist within the context of users. For example, if you’re at a Chamber of Commerce meeting and talking with small business owners about their accounting software and find someone who doesn’t use software, that might be interesting. Why doesn’t she use software? What does she do instead? Is she getting satisfactory results? Another group to consider interviewing, especially if you’re targeting a B2B market are stakeholders and decision-makers. Sticking with a product that streamlines the tracking of receivables and invoices, it might be worth talking to the manager of a Collections department. She might not be the primary user of the system, but there are probably use-cases or metrics she cares about that could influence the rate at which the software is adopted. Similarly, she might be able to provide information about who controls the purse and at what price/ value points, she or her peers can buy your product without needing another level of approval. tweet this! ! ! 14
- 15. Ask Good Questions While interviewing is a great tactic for getting feedback about your product, it can be difficult to craft good questions. All too often, the temptation is to ask leading questions that prompt the answers we want to hear. Remember, your baby might be ugly. Instead, focus on open-ended questions that are rooted in your observations and empirical evidence. The goal is to try and get to concrete information. Additionally, you want to avoid binary questions or questions whose answers would be represented on an absolute scale. Here are some examples of bad and good questions: Bad Question A Better Question Justification Is x an important feature to you? I noticed you never use x when you work. Why is that? People often overstate how important something is to them. Observing their actual behavior and asking them about it will yield more insightful responses. How often do you x? How many times did you x yesterday? People aren’t generally good estimators. By making the reference concrete, you’ll get a more useful answer. How much/big/little/etc is x? How much/big/little/etc is x relative to y? Absolute units usually don’t tell us anything. By comparing x to something else, you’ll get a clearer sense of it’s import. tweet this! ! ! 15
- 16. Asking good questions is challenging and takes time to learn to do well. Heck, we’re still constantly refining our own approach to asking questions. Just remember, the goal is to try and get as close as you can to first or foundational principles that motivate user behavior. The clearer you are about user intent and user motivations, the faster you can build them a successful tool. Once you’ve nailed down the problem, it’s time to start prototyping solutions (yay!). tweet this! ! ! 16 In Short • Good design is fundamentally about solving a specific problem for a particular type of user well. • The problem you first identify might not be the right problem to focus on. Brainstorm a few different problem statements to increase the likelihood of hitting the correct one. • Remember your problem statements are hypothesis until they’re empirically verified with user behavior or customer orders. • Use observation and user interviews to test hypothesis until you’ve nailed down the right problem.
- 17. Prototype Solutions Now comes the fun part. We get to build stuff! Once you’ve defined the problem you want to solve for your users, it’s time to start trying to figure out the best way to do that. Before you open up your text editor, IDE, or CMS, though, we’re going to (once again) caution against haste. The goal of prototyping is to quickly find out if a) you properly understood the problem you need to solve and b) your approach is the right one for your users. Don’t worry, you’ll get to build a cool app soon! Like defining a problem, prototyping also has a process you can use to start testing your ideas quickly. The four steps to the process are: • Transform your evidence into a design brief • Storyboard the setting, sequence, and outcome of the typical users’ interaction with the product. • Create paper prototypes and get feedback. • Create digital mockups and start to build something awesome. tweet this! ! ! 17
- 18. Create a Design Brief Once you’ve got your empirical evidence gathered (from your observations and interviews) and feel comfortable you know what problem to solve, it’s helpful to create a (very) short design brief that reflects what you’ve learned and will connect your design to a user’s context. This is especially useful if you’re working with a team; it helps to make sure all members of the team are on the same page. Your design brief will consist of the problem you’re trying to solve, the steps the user takes to solve the problem, the artifacts she uses in her process, her goals, and the points of pain she experiences along the way. This document will help to motivate your design choices. If you need help getting started, you can download the design brief template we’ve created for ourselves. User Steps Remember back in school when you had to write a paper describing how to make a peanut butter and jelly sandwich? This is similar. In order to influence what a user will do, we need to know what they do now. tweet this! ! ! 18 Components of a Design Brief: •User Description •Problem Statement •The Steps the User Takes to Solve the Problem •The Artifacts they Use •The User’s Goals •The User’s Pain Points
- 19. Returning to our invoicing example, what are some of the steps a user might take to create or process an invoice? The process might look something like this: • Open Calendar, Email, CRM, and Spreadsheet to prepare to invoice a client. • Go through calendar and input the total hours spent working for the client in the spreadsheet. • Next to the hours, type a description of the work performed. • Next to that, type the billing rate for those hours. • Multiply billing rate X hours in the next cell, then sum them. • Scour email to make sure there aren’t any missing hours. • Open CRM and find client’s email address. • Email spreadsheet to client. • Add a date in the calendar to follow up if the invoice hasn’t been paid by then. Again, this is just an example, the point is to outline the steps you observed or gathered from your interview. Already, though, you can likely spot opportunities to improve the user’s workflow. User’s Artifacts The next step is to identify the tools the user currently uses to solve their problem. Here, we’ve already identified a few: Calendar, Email, CRM, and Spreadsheet. tweet this! ! ! 19
- 20. The User’s Goals After your observations and interviews, you should have a sense (in the user’s words) of the goal that motivates the steps outlined above. It’s good to make them explicit and in the terms of the user as you prepare to design a solution. Additionally, you’ll want to make sure that you have some way of measuring whether the goal has been successfully accomplished or not. For example, if the user’s primary motivation for an invoicing tool is to get paid quicker, then you’ll want to make sure you measure the average time an invoice is open before it gets paid. The User’s Pain Points What thwarts the user’s ability to accomplish their stated goals? Chances are, this is where the money is! If, for instance, the user is struggling to get paid quickly because he keeps forgetting to follow up after he’s sent an invoice until it’s too late, maybe your solution sends automatic reminders to his clients after a certain number of days. Or, maybe it sends the user an update each week of aged invoices so he can choose to follow up as he sees fit. Putting these four things together will give you a robust picture of the user’s experience and offer important clues about how you might be able to solve the user’s problem. tweet this! ! ! 20
- 21. Storyboard Storyboarding is a concrete, visual way of representing the user’s context, workflow, and eventual satisfaction using your solution. Different from the design brief, this process doesn’t intend to reflect what is, but rather what will be once you’ve intervened. In this example, you’ll notice that storyboarding isn’t about winning an art contest. Rather, it’s about communicating ideas visually and clearly. Here, we can see our user recognizes that bills are due and he forgot to follow up on some invoices. He’s worried (Setting). So, he goes to his computer and logs on to the app. This is a logical next step in the sequence of events. Once he’s logged in, he sees that the system sent invoices on his behalf and they were paid. So, now he’s been paid and his frown has been turned upside down (Satisfaction). tweet this! ! ! 21
- 22. The specific number and types of sketches you’ll do will vary based on your context. In general, though, you’ll want to make sure that you are showing the user’s setting, the sequence they’ll follow, and the satisfaction they’ll receive once their problem is solved. A final note about storyboarding. The process isn’t intended to take a long time. Like brainstorming problem hypotheses, this should be time-boxed and collaborative. The goal here is to get your team’s ideas down on paper, make sure you’re interpreting the same story, and working towards the same end. Oh, and it should be fun. So, have fun with it! tweet this! ! ! 22
- 23. Paper Prototype Now that you have a thorough understanding of the user’s current activities and clear vision about how your product will lead to unprecedented user felicity, it’s time to start building paper prototypes. The purpose of this exercise is to test your understanding of the problem, process, and vision for the solution with real or potential users. Like the preceding steps, creating the artifacts shouldn’t take a lot of time.The goal is to get your ideas down on paper, then in front of users as quickly as possible. The artifact to the right, for instance, took just a few minutes, but is replete with assumptions: • That month and year are the right ways to visualize the chart. • That outstanding invoices and outstanding balance are the right pieces of information to show on the dashboard. • That users want to see the top 5 oldest invoices. Maybe it’s the top 10? Maybe they want it sorted by amount rather than days old? • What happens when a user touches “See All?” The chart? tweet this! ! ! 23
- 24. If we’ve been following the process so far, chances are that your sketches won’t be too far off and you’ll find the feedback you get from your users will accelerate your learning. You’ll also find that there are things neither you nor your users considered initially during the observation/interviewing stage. That’s not only cool, it should be expected. When building and showcasing paper prototypes, it’s often wise to approximate the user’s environment and go through the exercise with a partner. In the example above, we took a sheet of paper and taped it to an iPad. This allows a user to simulate what it might look like when they’re actually using the product. We could just as easily have used a phone, different tablet, or computer. After all, it just takes a little paper, some tape, and some markers to create a prototypical interface! When showcasing the prototype to users, it’s useful to have a partner go with you. Again, you’ll want to be stimulating the user’s environment, which means when the user touches “See All”, you should be prepared with the next screen they’ll be presented with, then place it on top of the device. It’s difficult to manage the experience, observe their interactions, ask good questions, and take notes by yourself. So, work as a member of a team. tweet this! ! ! 24
- 25. Digital Mockups If you’re a developer, this is the part you’ve been waiting for! Now, you get to code. We know, you’re super excited. And you should be, because if you’ve followed the process so far, the requirements of your beta system should be pretty clear. At this point, we still urge caution with respect to overbuilding. You should build just enough to reflect back to users the understanding you’ve gleaned from your observations, interviews, activity analysis, and paper prototypes. The interface should work, but the back end doesn’t necessarily need to. In other words, you’ll want to make sure users can interact with the tool and that button clicks lead somewhere. The extent to which you build a robust backend will vary depending on several factors including: • Your technical skill • Your budget • Whether customers are paying for you to develop a working product • The complexity of the build • The speed at which you can get a functional prototype working relative to your burn rate. tweet this! ! ! 25
- 26. While you’re building your digital mockup, you should still be getting feedback from users to make sure you’re building the right product. At this stage, you should also be thinking as much, if not more, about your business model and how the product will ultimately generate revenue. You should also be starting to think about how to monetize the users you’ve been interviewing via early access programs, beta trials, or the like. The details of that process are outside the scope of this book. We recommend checking out Steve Blank’s The Startup Owner’s Manual at this point (if you haven’t already). Whew! That was a lot. But, by this point you should have clarity about the problem you’re solving for the user, how it will fit into their ecosystem, and some sketches for how you might approach solving the problem. If you’ve followed along, you’ve already gone a long way in delivering value to a user and you haven’t invested a lot of time or money yet. Which is awesome. tweet this! ! ! 26 In short • Create design briefs that reflect your understanding of a user’s current environment. • Storyboard how your solution will change their world. • Create paper prototypes and get feedback from users to concretize your learning. • Create digital mockups to enhance the experience. • Remember, all of this is about clarity and communication; these steps shouldn’t take too long!
- 27. Evaluate the Design If you’ve been following our principles for user-centered design thus far, you should have a pretty good sense for the overall ‘look and feel’ for the product. But, little decisions will creep up along the way that you hadn’t thought of before. Should you take these back to users and get their advice? Surely, at some level, you should be making decisions on your user’s behalf without having to get feedback about every little thing, right? Of course. And certainly, once you start getting traction, you’ll have access to more and more information about how users interact with your product. While you should still be getting concrete feedback from users along the way, there are some basic evaluative techniques you can employ to make sure you’re providing a good user experience. It’s to some of these criteria we now turn. tweet this! ! ! 27
- 28. Usability Heuristics Heuristics are shortcuts or ‘rules of thumb’ that people tend to follow. In this context, we propose that they are ‘rules of thumb’ you ought to follow. While there are a variety of different usability heuristic schemes out there, one of the most popular set of criteria were devised by Jakob Nielson and Rolf Molich in 1990. Those criteria are listed to the right. Visibility of System Status Users should be informed about what’s going on. For example, if a user is logged in, make sure it’s clear that they’re logged in through the use of prompts, referencing their user name, or different menus. If an upload takes a long time, provide a status bar. Ambiguity about system status causes users anxiety. tweet this! ! ! 28 Nielson’s Design Heuristics: •Make the system’s status visible •Match the system with the real world •Allow users control and freedom •Use standards, be consistent •Prevent errors •Facilitate recognition, not recall •Be flexible •Use minimalist design •Help users recover from errors •Provide help and documentation source: http://www.nngroup.com/articles/ten- usability-heuristics/
- 29. Match the System with the Real World Use words and phrases familiar to the user. In other words, get rid of system codes or technical jargon that don’t mean anything to most users. For example, instead of having the typical “404 Error” show up when a user tries to access a page that doesn’t exist, just tell them plainly, “Sorry, the page you’re looking for doesn’t exist” and offer them a way out. Give Users Control and Freedom Users make mistakes. Where possible, give them the freedom to do so by supporting ‘undo’ or ‘redo’ operations. You should also have escapes that allow users to backtrack or switch contexts where appropriate. For instance, if you’re going to take users several layers deep in some menus, offer breadcrumbs so that they can get back to the appropriate top-level menu if they so desire. Use Standards, Be Consistent This is pretty self-explanatory, we think. Users shouldn’t have to guess what words or icons mean. Use familiar language, and consistent design or platform conventions throughout the entire application. tweet this! ! ! 29
- 30. Prevent Errors Providing good error messages is one thing. Preventing errors altogether is the moneymaker. Users often click on stuff, especially when feeling out the application for the first time. Do them a favor and prevent disaster by providing tooltips, alerts, or hiding information that may adversely alter state unintentionally. This is especially the case for “Delete” operations. Facilitate Recognition rather than Recall Users shouldn’t have to remember information as it migrates across the system. Nor should they have to copy and paste information from form to form. For instance, if they filled out some information on page 1 of your app and some of that information is necessary on a different page, then auto-populate the information for them. Facilitate Flexibility and Efficiency Another reason to observe super-users is to find out the tricks they use to work through the system efficiently. For instance, many users use a mouse to click from field to field or to accomplish tasks. But that might not be the most efficient route; maybe keystrokes or gestures are. By facilitating efficient habits, your users will get more value out of your system. tweet this! ! ! 30
- 31. Minimalist Design Every pixel should have a purpose. Interfaces cluttered with irrelevant or superfluous information confuse users and detract from the value of the important information on the screen. Provide users only the information they need, at the time they need it. Help Users Recover from Errors When users make mistakes, the error messages should be written clearly and offer a way out. Even better, they should empathize with the user and suggest a solution or different course of action based on user intent. Provide Help and Documentation Ideally, your system does not require documentation. But, as the userbase grows and edge cases arise, you might need to provide some documentation. Make sure it’s easily accessible, easy to search, and offers concise, concrete guidance that solves the user’s problem. tweet this! ! ! 31 In short • Nielson’s Design Heuristics can help you evaluate the quality of your design on a user’s experience. • More information can be found here: http://www.nngroup.com/articles/ten-usability-heuristics/
- 32. Learn and Iterate By now, you’re really cookin’! You’re doing an awesome job solving a worthwhile problem for your users. Your interface is clear, facilitates human interaction, and your product is growing like gangbusters. You’re living the dream. Can it get any better? Yes. Always. Particularly with digital products, you should make sure that they’re instrumented and that you’re using tools to measure how the product is being used. For instance, you might want to track: • How many users are coming online each day? • How many convert to paying customers? • What are the most likely paths to conversion? • Where do users linger? • Where do they get stuck? • And so on. tweet this! ! ! 32
- 33. While many of the specific metrics you’ll care about will vary based on your product and users, there are a few principles you’ll want to make sure you follow: Define the Metrics that Matter Remember, your goal is to solve a problem for a set of users. So, at the very least, you should be tracking user growth and your effectiveness at solving that problem. As a business, you should also care about the monetization of users and the paths that lead to monetization. Whatever those metrics are, be careful not to go crazy. Only a few metrics are really critical, after all. Make sure you pick those critical few that matter most and measure them relentlessly. Experiment No matter how awesome your product is, it can always be better. The same is true for your interface. So, you should make experimentation a habit. tweet this! ! ! 33 Typical Metrics for a Web Product: •Visits & Visitors •Time on Page •Time on Site •Bounce Rate •Conversion Rate •Exit Rates source: Web Analytics 2.0, Avinash Kaushik
- 34. Experimentation can take many forms: it could be different algorithms, different interfaces, different verbiage, and so on and so forth. Again, the nature of your experiments will vary based on your product and the habits of your users. But, at a minimum, you should make sure that as you’re tracking the metrics identified above, you’re constantly tweaking the product to get to the next level. A/B Testing Split, or A/B testing, is a great way to get started with experimentation. Let’s say, for example, that as you’re reviewing user clickstreams, you feel like some additional navigation menus would be useful. Should they go at the top of the screen or on the side? A great way to test this is to build two versions - one with the navigation on the top and one with the navigation on the side, then evaluate which one seems to make most sense to the user. This is the heart of A/B testing: you build two versions, instrument them, then have them compete with each other. The one that yields the highest marks (based on the metrics you care about) becomes the ‘winner’ and gets rolled out to more users. The other design gets retired. tweet this! ! ! 34
- 35. Evaluating Success Before you start A/B testing, it’s helpful to make sure you’ve established baselines for performance. A baseline is ‘the status quo’ and will serve as the foundation for your evaluation of ‘success.’ It should also be the metric(s) you count as the dependent variable(s) in your experiment. The independent variable is a related measure that you’re going to adjust such that it should influence changes in the metric being measured. Ideally, you’ll be looking for causal relationships: if I change x, then y goes up or down by z%. Of course, real data is more complex than this, but you get the idea: when you’re testing designs, make sure you know what measure you expect to change and what factor(s) you’re tweaking to affect that change. Iterate Circumstances, technology, and user expectations change. By adopting a learning attitude towards your product, choosing relevant metrics, and experimenting, you should be able to iterate constantly and keep the design fresh, functional, and delightful to your users. tweet this! ! ! 35 In short • Measure the things that matter most. • Experiment. • Learn and iterate constantly.
- 36. Conclusion Great design delights users. It makes them more productive, more efficient, and more likely to share your product with others. Poor design frustrates users and increases irritation. And your users already have more to do than they have time to do it. Users may still use your product (because they have to), but as soon as the opportunity comes to switch, they certainly will. Good design isn’t just about pretty interfaces. It’s about solving real problems for user who matter. Even if you aren’t Steve Jobs or Jony Ive, you can still create a great product. We’ve outlined an approach that will help you to accomplish this. If you do, you’ll delight your users and they’ll surely appreciate you for it. Thanks for reading. tweet this! ! ! 36 The Design Process: •Define the Problem •Prototype Solutions •Evaluate the Design •Learn and Iterate
- 37. Learn More about Cognite Labs Cognite Labs crafts apps for the mobile web. We can help you through all stages of the design process and help you to build a good product for your users and/or customers. We can also help with staff augmentation if you have a functional product and need some help moving faster. Want to learn more? Visit us on the interweb: CogniteLabs.com Or shoot us a note: info@cognitelabs.com Did you like this book? Please tweet it! tweet this! ! ! 37