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