Home / Books / Product Design for the Web
Product Design for the Web: Principles of Designing and Releasing Web Products
9/10

Product Design for the Web

Randy J. Hunt

Solid introduction to the process of designing web products from the former lead designer at Etsy. The book covers a lot of incredibly useful stuff like what to expect when designing a product, the differences in workflow compared to client work, and strategies for designing good products. Definitely a must read for anyone working at a startup, working as an in-house designer, or creating their own products.

Buy it

Highlights and notes

“People think that design is styling. Design is not style. It’s not about giving shape to the shell and not giving a damn about the guts. Good design is a renaissance attitude that combines technology, cognitive science, human need, and beauty to produce something that the world didn’t know it was missing.”

— Paola Antonelli, MOMA’s Senior Curator of Architecture & Design + Director of R&D

The “product” was this thing we were building: the Web application, mobile apps, and the API (application programming interface). Many people hear “product” and think of a toothbrush or a toaster. At Etsy, the product was (and is) software.

After reading this book, you’ll have a much more complete understanding of what’s involved in designing digital products, how that design process works, and how to do it well.

Anyone working in the field of product design, Web design, online media, entrepreneurship, software development, or management and leadership will find value in what follows.

This book will guide you in exploring the principles of designing and releasing Web products. You’ll learn how to conceive and implement design decisions that can support the full arc of a person’s experience with a product. You’ll learn what types of product can engage and serve the people you’re building for. You’ll also learn how the product can shape their responses and meet their goals (and yours) as they use it.

First, let’s ask what is a Web product? What makes a product a product?

A website is not a product

Imagine a fabulous restaurant called Bella’s. Bella’s website works like a brochure. But a “brochure site” isn’t really a product. It’s mostly static content—and your interaction is largely limited to browsing that content. So Bella’s website is not a product—but it might be using a product. Behind the scenes, Bella’s “brochure website” uses a product. As the owner of Bella’s, you’ve been using a Web product every day to manage how you present your business online, how you communicate specials, and how you build your business’s reputation and relationship with customers.

The Web product you use may look like a website on the surface; but upon further inspection, you’ll find that its features, functionality, intent, and design are very different. You might be using the same Web-browsing devices—computer, tablet, or cell phone—to access a website and a Web product, but there are profound and powerful differences that should influence how you design.

Attributes of a product:

  1. Frequency of use

    While users may visit a website occasionally (perhaps the most frequent use would be visiting a news site), a user may visit a Web product over and over again.

  2. Direction of data and content

    A website typically passes content (text, photos, video, or audio) in only one direction—from site to visitor—a Web product will both deliver and receive content.

    A website is often a consumption-only experience, whereas a Web product is a creative or participative experience.

  3. Navigation vs. participation

    A website interface is tailored for the consumption of content. A product interface includes more complex and multi-state interface elements that enable user input.

  4. Presence of accounts

    In general, websites are accessible without logging into user accounts. Products often incorporate experiences and services that require unique user accounts.

  5. Pages or flows

    Website content may change over time, but the views and presentation are relatively static. It’s common to refer to these views as “pages” because they’re like the unchanging printed pages of a book. A Web product is highly dynamic and includes many views. Each view often contains many states (such as a default state, a recently changed state, an error state, and an empty state), any one of which might be displayed to a user. Products often spread features and functionality over a sequence of views (typically called a “flow”).

  6. Beyond the browser

    While the website experience is limited to content browsing, a product may extend to other services, such as sending emails to your inbox, routing text messages to your phone, or communicating with an installed app on your computer or mobile device.

Product types:

Not all Web products are the same. Some products are fully experienced as stand-alone products. Other products are best experienced as part of a suite of products, and still other products are created as platforms upon which other products are built.

Stand-alone products are simply that: a product that provides its full intended experience and value when you use on its own.

Ecosystem products are products that require more than one “connection point,” a term I use to describe “stuff” that’s more than me and my information at any one moment in time.

Examples of these other connection points are other people, products or services, and third-party apps that allow me to use the product at many times, in many locations, or on various devices.

Ecosystem products often need friends. They import lists of people, connect to your other online accounts, allow you to search for people, and proactively suggest other people you might connect with.

By virtue of connecting to other people, the ecosystem product not only includes information that you input (or is generated for you by the software), but also includes information and experiences that come from other people within the ecosystem and are automatically pushed to you.

In addition to connecting to other people, an ecosystem product may initiate connections to other products or services. A great example of this is a product called IFTTT.

Ecosystem products often have connection points that are Web products and native apps.

Platform products support and enable features and functions for other products and are frequently invisible to the general user.

The lines between these different product types aren’t always clear cut, and products may change over time. As they become more sophisticated and full featured, many products evolve from stand-alone products to ecosystem products to platform products. Many of the most mature products become all three product types.

Apps that you run directly on your device, rather than within a Web browser, are often referred to as “native apps.”

After using apps for a few years, I’ve come to believe that we should think about apps as we think about Web products.

Web products never have to be installed. Rather, they simply “exist” at a particular URL. Because of this, they are available to every browser everywhere

Because the product code lives in one place, rather than being installed on every individual user’s device, a browser-based product can be changed instantly and updated for every user in the world.

One of the most obvious reasons native apps may be preferred is that a native app has deeper access to the hardware of mobile and native devices (resources such as memory chips, attached storage devices, cameras, microphones, GPS data, and so on).

Although this assertion is often contested, it’s generally true that native apps perform faster and are more responsive to user input. In other words, they often “feel” better.

in some cases your audience may prefer native apps to Web apps for any of the reasons above, or for less understandable reasons rooted in the perceptions of your target audience. They may prefer to buy software and have a sense of ownership, in which case a native app may be a great fit.

Allowing Web products and native-app products to drift too far apart in your mind can compromise a well-considered product experience. This result would likely be bad for the continuity of your brand and image.

Usually when a product designer is working solo, she’s doing most, if not all, of this work, herself. She might be wearing all of these hats and not even realize it.

In the world of product design I’ve come to know, “user experience” is about as misused and misunderstood as “brand.”

Product design tries to create an experience that is both understandable and meaningful.

One piece of the product is the interface that people interact with directly. Even though I prefer “person” over “user,” let’s accept the established terminology of “user interface,” or UI. People responsible for the interface are often referred to as “visual designers” or “UI designers.”

Interaction design (IxD) is the design of the behaviors and events that compel a person to interact with the product and determine how the product responds. The interface design involves such decisions as the placement of buttons and whether they even look like buttons. The interaction is the behavior of those buttons when pressed.

The interface elements must accurately reflect their intended purpose. When a person interacts with those elements, the result should fulfill the person’s expectations. So, a superior product design includes behaviors that are either familiar to the person or appropriate to the content at hand—often both.

The understandable experience is one that:

IA, another of the initialisms I love to hate, stands for “information architecture.”

The information architecture process involves observing and analyzing complex sets of information, and then designing a system in which they can be better organized, better programmed, and better understood.

The terminology, grouping, and hierarchy of this information are important to the experience of the product. Creating a suitable taxonomy for this information is important for ensuring that the product is easy to use and evokes positive responses from first-time users.

Product management is the glue of the product development process. It tends to stick together all of the disciplines and relate them to each other. I remember once seeing a job ad from a company seeking a product manager who would not only ensure the trains ran on time, but also would help build the track. That’s a perfect metaphor for summing up the role and scope of product management.

At Etsy, we like to say that “Project management comes for free.” That means that the best engineering managers or designers or product managers are also very good project managers.

Product managers balance at least three things, and in doing so can help guide the path the product takes. These three things are:

In my mind, UI is synonymous with visual design.

Interaction design is more concerned with the behavior of those interface elements. When I click that button, what happens? When I click a similar button, does it trigger a similar behavior? Can I encourage a specific user behavior by placing certain elements of the product interface in different places?

Engineer. Programmer. Developer. All of these terms kind of mean the same thing. This person’s primary role is to write the code to make the product work.

Writing is an extremely important and often highly underrated aspect of product design.

Sometimes the best design change isn’t a visual or interaction design change; it’s the improvement of a button’s text or a form input’s label.

Product marketing assesses the features, attributes, and positioning of the product and delivers that message to its audience.

Research, in one form or another, is always part of the product design process.

Research can, and likely should, happen before, during, and after you’ve built a product.

When you’re able to wear many hats—even if you don’t need to each day—you and your product design will be better for it.

The people who think this multi-talent is impossible to find call these mysterious multi-talented designers “unicorns”: the designer as mythical creature running in the enchanted forests, never to be found.

Designers with a combination of skill sets and experiences, with deep knowledge of many different disciplines, do exist in the world.

Why this insistence that such and such combinations of skills are impossible to find or, worse, inappropriate? I’d chock it up to fear (“Do I have to learn all these new skills?”) and uncertainty (“I don’t understand how this works, so I don’t like it.”).

Crafting, telling, and sticking to a story can help you build your product with a sense of direction and purpose.

By defining the impact you want your product to have as you first begin working on it, you’re more likely to understand the choices you can make.

One product development technique that has become quite popular is the exercise of writing the press release for a product as the initial expression of the product idea.

These basic facts in the release are essentially the who, what, where, when, why, and how components of the product’s story:

The exercise of writing a press release channels your thinking into a form that is outcome oriented. In other words, it forces you to focus initially on the end result of what you’re creating rather than getting mired in the details.

Who will care that this product exists, why is it important for them, what does it do for them, and how does it do it?

Every story needs a beginning, a middle, and an end. Your articulation of the narrative—in the previous example, a press release—is your beginning. The consistency of product vision is your middle—the meat of your story—which carries you throughout a journey of twists and turns. The outcome is your end product.

Every aspect of your design should take your protagonists through the story arc that you’ve chosen for them. If you’re delivering information, that arc is going from uninformed, to learning-motivated, to gaining a final answer. If you’re selling a product, that arc goes from curiosity and browsing, to locating a desired item, to final purchase.

It’s important for us to consider exactly what we are creating when we design a digital product: how it is experienced, how it is constructed, how it works, and the connection between those three factors.

Instead of a page, we design a flow, a word that implies a looseness of movement and, perhaps, an unpredictable pathway.

Flow as a model also implies the passage of time.

The elements that can appear or occur within a flow aren’t limited to its presence on a specific medium, device, or screen. A person may interact with the flow through an app or online shopping site, but she is also interacting when she tells her friend about her experience or sees a printed ad in a favorite magazine. Each interaction helps that person understand what the product looks and feels like, how to use it, and whom it is for. Each of those moments is part of a larger flow that easily moves from online interaction to offline activity and back. A flow has the potential to go in a variety of directions, change its pacing, and be subject to manipulation and multiple interpretations. Knowing this, a designer can thoughtfully and creatively craft an experience that never reaches a dead end. A dead end is a missed opportunity.

Finding moments to extend flows demands broader thinking.

Often, the next possible destination for a flow will reveal itself only as you’re actually developing the product from your design.

When you are refining a part of a product experience design, you must always be looking for opportunities to extend its flow.

When you’re dealing with an unpredictable flow, the key to finding new opportunities is simply to open up to the entire world of possibilities.

If you’re looking to turn a dead end into a not-dead notend, consider connecting it to other key flows—those essential flows that make up the core of your product and already exist in the experience.

How can you continually extend the experience so that it remains beneficial for you and the customer?

If we understand that a flow is a set of experiences that people have over time while interacting with your product, we should recognize that “over time” can mean a very long time, indeed.

Also consider that you are working on a product that lets people start an experience now that might conclude in the future. Those events could happen now or a decade from now. The user experience can become very long. You have to think differently about how you would create that flow so you don’t accidentally create a dead end later.

Sometimes as you work you will see the connection points between parts of the product experience, and sometimes they will not appear for a long time. The design process is always one of discovery. When we design a product for the Web, discovery is an important part of how we determine what the product actually is.

It’s up to the designer to help the user to understand, “What am I going to get out of this?”

There has to be a reason for that person to continue with the experience. Whether it’s informative, useful, or just plain fun, the ongoing path you create makes it more likely that the user will stay with you on the journey through your product.

Some elements of a product design can’t be seen. I call them invisible features. They aren’t easily detected, but they are essential to the success of your product and the quality of its user experience. Invisible features are as important as those features you can see—sometimes more so—because of the emotional impact they have on users. As a result, these features must be considered as you design and plan your product.

Invisible features:

Early impressions quickly start to cement her opinion of the product. Invisible factors can be steered by your design, thereby improving your chances for success.

Performance is measured by how people expect the product to work.

A slow website or app doesn’t feel “right.” The user will assume that something is missing or broken or that the product isn’t as good as other products she’s already used.

Speed is a major factor when customers gauge performance, and it can cut both ways. Speed represents the power behind the product.

In your design, you can manipulate the elements that affect speed:

But to guarantee a fast, positively perceived user experience, you must test your creation in as many varied and difficult conditions as you can dream up. No matter how much you optimize, there are always more ways to accelerate your product.

Speed can cut two ways. A product that is too fast can generate as much user unease as a slow product. Imagine that you are making a big purchase online, and you click the button to confirm your purchase. If the purchase is completed instantly and there’s not enough visual feedback, you might not have a lot of confidence that the transaction actually took place. The act of waiting in an experience like this helps create the impression that a more complex action took place than a lightweight product interaction.

The heavier the importance of the exchange, the more carefully the pacing should be considered. When people are dealing with money, health, and other weighty issues, speed can be eased off a bit. I recommend a simple exercise. If the interaction is something you’d take a deep breath before completing, then take that breath! Use that breath as your measurement for a reasonably paced response time. Click. Deep breath. Response.

How can you make speedy performance visible? From time to time, you might tell your users how quickly your product works—any quantifiable value can work. You can gather endorsements from outside parties that speak well of your product’s performance (such as with a quote about how quick it is). Or you can render speed metrics that are relevant to your audience, such as “this search took 1.872 seconds.”

Reliability is another important part of performance. It’s characterized by a product that functions consistently, is free of bugs, doesn’t crash, and fully loads every time. Its buttons respond each time you click them, and any gestures on a touch screen feel natural and appropriately responsive. That is, they accept your input but do not capture accidental actions.

Another aspect of performance and reliability is consistency over time.

Your product must be able to accommodate change. However, understand how change feels to the user: a product that changes too often may convey unreliability.

Constant change can be upsetting. At the same time, the longer the product has been around and the longer the time between changes, the more upsetting a change can be.

Change may also make the user believe that something was previously amiss. Without an explanation, the user does not understand what you are doing—even if the change was a big improvement.

An established, enthusiastic community gives new users a sense of security, assuring them that they are making the right choice. It also reinforces a sense of belonging for longtime customers. So you need to find a way to make the concept of “community” visible to your users.

Community actually has two parts. One part is your internal community. It can include customer service, industry and business partners, and the people who build the product (that’s you!).

The other part of community is the external community.

The biggest source of this external community is your growing pool of customers.

Support is the availability of resources, people, and/or information that can address a problem if it occurs.

It’s tough to plan a support system that is comprehensive enough to address everything, but if a responsive system is not in place, customers will definitely feel it.

It’s not enough just to have great support, though; you also have to make it visible through your marketing and in your product.

Customer satisfaction reports provide a metric that is widely respected. Track these reports and share them with customers.

Security relates directly to a sense of control. If a user feels that things are out of his control, he will not enter into a relationship with your product.

Several visual cues can be used to imply security. You’re surely familiar with seeing an icon of a lock or a safe on a checkout page. Although they are not required, don’t underestimate the potential power of such cues.

Because performance, community, support, and security are invisible, they are easily overlooked. But when they become visible by their absence, their importance becomes too clear, too late. Each of these invisible features should be designed as carefully as the visual elements of your product.

The more positive emotional connection between the user and your product, the more forgiving that user is prone to be.

You build trust equity over time. If you do a very good job most of the time, customers will cut you some slack when you do make a mistake. But you can’t do that very often, and when it happens, you have to rebuild.

Certain unanticipated situations can cause you to miss the advantages provided by well-designed invisible features:

Look at your product through the eyes of a person who is frustrated when things are slow, stops using an app that crashes, or doesn’t trust a site with a publicized security breach; also look at your product as a customer who responds to a feeling of community with your product as well as feels like a responsible user of customer support. Make design decisions to create an exciting—and dependable—product experience for that person, so she can use your product without ever worrying about the invisible features. That’s your job.

What is your intention for a product, and what is your user’s intention for it? Every other consideration is secondary.

In every Web product you create, you should prioritize effective over clever. [I can’t highlight this enough times]

During the design process, you can easily want to surprise and delight the user. So you create a design element—an interaction pattern, a naming scheme, a symbol, and so on—that is fresh and extremely inventive. However, the cleverness of your creation obscures the intent of the product. And the cleverness of that first impression doesn’t hold up over time—and I don’t mean over years; I mean over only the first few moments of use. After that first rush of newness, if the intended value of the product is not clear, or the functional intent isn’t obvious, the novel idea means nothing.

What cleverness factors work against the intent of a design?

  1. Unclear Naming

    When you are introducing a new product or trying to attract new users to an existing product, clever language just puts more hurdles in the way of potential users. Every conceptual leap that you ask users to make reduces a product’s potential for success.

    Does this mean that designers must produce dull, pedestrian work? Of course not. But the cleverness or “extras” that you add to a product should be like a little salt and pepper sprinkled on a well-prepared dish. They can add to and even improve the recipe, but the seasoning should not be a main ingredient.

  2. Newness for Newness’s Sake

  3. Pressure to Create a Marketable Product

    The need to creatively market an updated product sometimes pushes designers toward overly clever choices.

  4. Personality Mismatches

    Every design feature must consistently fit the personality of the product.

  5. Correct Action, Wrong Application

    It would be confusing to assume that a user would intuit that she should swipe her finger to the left to stop a file from loading, for instance. In that context, the swipe doesn’t match up with any previous user experience.

Problems arise when interface designs:

The designer’s role is to reduce a product design solution to an idea that’s as familiar and understandable as it can possibly be and still ensure that the product works as intended. Your goal should be to make sure that your design is usable and, therefore, is used by its intended audience. Products shouldn’t be epically creative, or try to break perceptions, or ask a user to consider a whole world of new.

Your usability filter should be turned way up as you design. Every design choice you make should be viewed through that strict filter. Does this choice help the user? Does that choice improve her experience? Does it throw elements in her path that waste time and energy? (If so, the feature also wastes your time and energy.) Stay focused on your primary intent.

Have you ever worked with a writer on a project and, when you were done, felt that the project had too much text? That’s because writers tend to solve problems with words. Designers are inclined to do the same. They tend to solve problems by over-designing features. It takes a selfless, critical eye to avoid over-designing your product. Just let it be what it wants to be.

Before you try any other design solution, see if the standard solution will work for your product. In other words, un-design the experience before you design it.

Always remember that the cleverness should be in the product’s concept, not in its execution.

For me, it is exciting to see people successfully using a dashboard that I designed, for example, and I’m proud of how well it works. We become more satisfied with our design choices as the product matures and as everyone—users and designer alike—gets to know it better.

Backward Satisfaction: The creative joy isn’t in the cleverness of the product; it’s in the use of the product.

Unless your design choices reward people for using your product in the way you intended—and in a way that benefits them—you are not their true advocate. In fact, you might be punishing them, which is unlikely to make them love your product.

If you want people to love your product and recommend it to others, you must always be offering positive reinforcement.

At the start of their experience, show them examples of what you want them to do.

That’s an important goal for the product designer: to reward the user with success from the earliest possible interactions.

Make implicit what is intended. Instead of (or in addition to) explaining your product, your design choices can also imply what is intended.

Make explicit what is intended. All along the way, offer encouragement and feedback when the user does what you want him to do.

Discourage unintended behavior. There will be times when a user will unintentionally head down a wrong path. The easiest way to prevent this is to remove the opportunity for error in your design.

Reward intended behavior. When a task is successfully completed, you want to use simple rewards to encourage people to repeat that behavior again and again.

You can also reward good behavior through game mechanics, which basically use rules to encourage people to become engaged with gameplay.

Another way to reward users is to give them access to information that is inaccessible to others.

From time to time, you will have to contend with users who are intentionally misusing your product.

When people use your product incorrectly, it can create a less-than-ideal experience for other users.

Consider first what that person’s motives might be. Perhaps he did not fully understand your rules for use. In that case, your instructions may need to be improved.

In these cases, the misuser isn’t trying to be malicious but has accidentally come to the wrong party.

When a user simply refuses to comply with your rules of use, you can:

The reason for building with frequent changes is simple: We create living products.

We should create designs and share them with peers and customers, consider their feedback, adjust and redesign, and repeat the process over and over again on the way to developing a whole product. We should build quickly but responsively.

When you constantly collaborate with peers and customers, you receive gifts in the form of feedback. Don’t treat ideas as precious commodities that you must save for the big reveal. Ideas are cheap and easy; it’s making them happen that’s valuable and difficult. Input from other people makes those ideas even more valuable.

Everyone’s efforts should be directed at making the product better. You want to ensure that design skills and creative energy are all going into the product, not into unnecessary—and unnecessarily fancy and polished—presentations.

Make the least possible investment in communicating an idea. Don’t suffocate the process with Photoshop renderings or laboriously detailed sketches. Invest just enough time in your sketches or descriptions to communicate the essence of what you are trying to do. When you are trying to validate an idea, the simplest method is always best.

Getting early feedback on your designs validates your efforts. If a new app feature doesn’t make sense or isn’t wanted by your customers, early feedback stops you from wasting time and energy developing it.

There’s an interesting marketing technique called false doors that can help you test a product idea and gauge the interest of customers. You share your idea (in a semi-concrete way) with potential customers and collect their feedback. Say that you want to test your idea for opening a pizza parlor in a certain location. Will there be enough traffic and interest? To find out, you create a simple sign that reads, “Pizza: $2.50 per slice,” and for two weeks, post it in the window of the storefront where you would like to locate. If people enter the vestibule, they will see a “coming soon” notice and be able to leave their email address so that you can contact them when you do open.

You can do the same thing with product design for the Web. Imagine that you have a new mobile application that allows people to keep track of their favorite pizzerias. You might want to introduce a new button that reads, “Publish to my profile.” You can create a false door so that when someone clicks the button, he or she sees a “coming soon” or “notify me when available” pop-up notice. The feedback you can collect when people click this false door will help you determine how many people might be interested in your new idea.

By getting feedback early and often, you can make regular (and much less painful) corrections to your plans rather than pushing out large and often demoralizing changes. Small changes mean less work for you and less adjustment for the customer.

Problems will arise with any product, no matter how many times it is tested. The ship-early-and-often method of product development can also help us more easily solve these problems. Here’s why:

Your design may be released to customers who are happily using it. Now it’s time to look at it again with fresh eyes.

Why would we want to “rinse clean” when we’ve been building up all of this product knowledge through testing, experimenting, and research? Because it’s a thought exercise—sort of a brain-bender—that can force you to arrive at design solutions that aren’t possible within another problem-solving process. It’s about pursuing the same goals, but redefining the problem each time to force yourself into creative problem solving.

It is clarifying to know from the start what your goal is and to maintain that goal throughout your design process.

Some example goals might be:

As you rethink and redesign, force your brain not to be limited by what you just did.

The desires and needs of the people who already use or who will use your product are the most important considerations in your creative process.

A specific product may have quality, styling, and an excellent feature set, but unless it matches people’s desires, their social nature, their intellectual levels, and their experiences, the product will not succeed. At the end of the day, people will be using your product. So you must put their needs first.

So how exactly do you find out what makes products valuable to people? You can just ask them, but even before you get to that point, you need to answer some very basic questions:

Watch and observe people because what they say they do may be vastly different from what they actually do.

Listen to your customers and to your potential customers as well.

More than designing answers or engineering solutions or creating marketing plans, the one thing you have to remember in developing a new product is the people who will use it. Ultimately, everything goes back to them. The better you understand this and the more it remains top of mind, the better your products will be.

Identify where the problems and opportunities are, and write them down. This is a statement of intent for the next phase of your design process.

Identify each component, and you have the information in hand to start a thoughtful design exploration, while keeping the following in mind:

The problem or weakness can be big or small.

A strength could be a solution that solved an earlier problem and could be reapplied, a part of the existing product experience you could build upon,

A tenet or approach is your statement of what you believe to be your intent as you start the design.

How do you know that your idea is going to work? The short answer is: you don’t!

If your informal validation says that the idea doesn’t have traction with your users, but you feel strongly about it, consider the simplest way to take it a little further with the lowest research investment.

It can be difficult to validate some ideas by only describing them or showing sketches or pictures. You may have to actually build something to get it as close to real as possible. That’s often called a prototype,

One of my strongly held beliefs is that there should not be much difference between prototypes and the end product itself.

You might sketch things out on paper very quickly, just to capture your idea, and show it to others for input. But the very next step should be prototyping, during which you try to use the exact same tools (software, platforms, code) that you would use to build the actual product.

Work quickly: Nothing has to be clean and perfect.

There are two primary ways to test:

Automated testing uses software (that you can create yourself—it’s just another product) to locate failure points.

Every time you release a new product or any revision to an existing product, it should be tested.

In some cases, you might turn on your new product all at once. Ta da! We generally try to avoid actually doing that, but it might look or feel that way depending on how we communicate the release.

In many cases, we slowly release our product. If your tooling and infrastructure are sophisticated, you might even release to only a percentage of the people using your product.

Once you’re confident that your product is working as expected, and that it doesn’t have any surprise problems, you can release it more widely. This approach is common for large and complex products.

As you first start product development, it may be premature to use approaches like partial releases,

Once your product is in use, and people are interacting with your design, it’s time to start observing again by collecting information, evaluating that information, and learning from it.

The degree to which you can collect information will probably vary based on the maturity of your product.

As most people know, change for change’s sake is worthless and irritating. But change that brings clear benefits makes everyone happier.

Always be listening to your customers.

Most customers don’t yet know what they want, or at least they can’t verbalize it.

People aren’t comfortable with change, but the whole world is about constant change.

It’s a world where being tool-agnostic is crucial, if for no other reason than that new and potentially better tools are being developed all the time

It’s important to have a point of view regarding tools because they shape the way you work.

It stands to reason that solutions are also shaped by our choice of tools. If you have a hammer, you tend to solve problems with nails. But tools should always be secondary. I would never rigidly commit to one or another tool.

Don’t let the tool dictate how you work.

When possible, use tools that are as close as possible to your product.

The actual tools don’t matter that much as long as you use them regularly and become skillful with them. If you have chosen a tool and found it frustrating to work with, then it is probably the wrong tool. Ditch it.

The tool that allows you to work quickly, confidently, and comfortably is the best tool for you.

Don’t be afraid to create your own solutions.

Don’t choose tools that force you to work in ways you don’t like.

The following tools are common to most product designers.

Start with simple tools and prefer simple tools. Don’t get too clever about them, or opt for complexity in anticipation of what you might need in the future. Use what works for you right now.

Add new tools when your current tools aren’t sufficient for addressing new problems.

Feedback—positive or negative—is very valuable.

The forms of collecting feedback—research—can be categorized into one of two buckets: quantitative research and qualitative research.

Quantitative research is research that you can measure with numbers.

Qualitative research gathers feedback on the kinds of things that you can’t easily count and put into numerical form—feelings, tastes, unstructured observations, and responses to open-ended questions.

Qualitative research usually requires subject area experts to help craft questions and interpret results. Without some expertise in market research, it can be easy to ask leading questions or misinterpret information.

You don’t need to gather every kind of feedback for every iteration of every project.

“eat your own dog food”: Get the product operable as soon as possible and start using it so as to develop immediate feedback loops.

To acquire casual feedback, you might ask co-workers and other people who are not directly related to the project—friends, family, and acquaintances—to review early trials.

The value of this sort of collection is that it is within reach, it’s generally accessible, it doesn’t take a lot of time, and it’s inexpensive.

At the most formalized end of the feedback-gathering spectrum is user testing, conducted by professionals.

The expense of this level of research often puts it out of reach for bootstrapped operations.

Steps of the feedback collection process:

  1. Decide what to ask. What do you want to learn?
  2. Through verbal inquiry, observation, or data collection, collect the information.
  3. Listen to and carefully consider all information. Don’t cherry-pick just what you want to hear.
  4. Interpret what you have learned and derive conclusions from it. The answers may not be immediately actionable, so you need to translate the information into a future plan.
  5. Decide what to do with the answers.

Accept that you will benefit from being inclusive rather than exclusive. Open yourself and your process to the ideas, experience, and intuition of others.

The hardest part about working by yourself is you! You’re going to be stuck with that voice in your head, both encouraging and nagging, so you’d best learn how to work productively with it. Even if you do, you may want a surrogate team to help you have new insights and different perspectives. Find a community of people, in the real world and online, whom you can connect with, and lean on them. Identify a mentor, someone who has been there before, and query him or her frequently.

Many products are designed and built by small teams of people. Small in this example is what I might also call optimal: four to seven people.

Committing to an iterative design process also means that collaboration points and compromises are temporary, not calcified. The group will spend more time learning and making, and less time selling, politicking, and pontificating.

When you develop a small team, it’s best to have a business plan in place from day one. Developing a product can take a long time (really, it never ends when you are making small and frequent changes), so it’s best to map out a safe path in advance to reduce risk.

If you’re working in a big team or are growing into one, know this: Big teams don’t work.

So, how do you work in a big team if big teams don’t work? You need to break big teams into smaller teams, and subdivide big projects into smaller ones.

A team of teams requires careful and constant management. An unmanaged team tends to work too much on justifying its existence and less on getting the hard work done.

How can you make those dynamics happen with a team of teams? It may require a torch-bearer—a believer in the process, mindset, and methodologies—who will help make the product design principles visible and mutually valued.

When you have a team of teams, focus subteams on meaningful parts of the product.

Because we know that people using the product will define the success of the product, it may be beneficial to organize your subteams around the demographics or activities of those people. That might mean a different team for different audiences (core users, advertisers), different use-cases (shopping, selling), or different products entirely (your commerce product, your content product).

If you’re looking to build a team, think of simple, small changes. The same goes for evolving from a small team into a larger team. Drastic changes can shock the system.

[The major difference between designing for clients (like at an agency or as a freelancer) and designing a product full time:]

Designing Web products, particularly your own product, is drastically different from designing on demand for clients. When I was designing for clients, a known end was always in sight. At some point the project would conclude, final payments would be made, and the design would be out of your hands.

I’m not sure about you, but the first version of a design I send out in the world is rarely the best version of it. As soon as it reaches its audience, I realize there are things I could and should have done better. More importantly, I begin to hear reactions, see how it’s working, and determine if and how it was successful. When you’re working with a client, you usually don’t have the opportunity to do anything about those discoveries because the product is no longer yours. The most you can do is internalize those lessons for the next project and the next client.

Designing Web products is also quite different from creating physical products. Because Web products are software-based digital products, they are fluid and changeable; it’s easier to evolve digital products.

Web products are never finished. The product can, should, and will change. The choices that were made initially and the design decisions that were implemented are not precious. They must be seen through a critical lens and never stay the same simply because the design team isn’t willing to improve them with new knowledge.

The product you create is characterized most of all by the expectations of the people who use it.

Dead ends hurt your product experience. Avoid them.

It is crucial to be reductive, straightforward, and simple in your design, and waiver from that approach only when a digression is a central part of a high-quality experience. Everything else is a distraction. A product should be usable first, and magical second. Spirit without utility doesn’t last. Utility without spirit isn’t memorable or compelling.

Any well-designed product has many underlying features that may not be apparent on the surface. Speed, reliability, and user support—these and many other factors may not be evident even after you have thousands of users, but their absence can spell disaster for a product.

It is possible, through design, to shape people’s behavior, to motivate them to take the actions that you want, and to prevent them from doing what you don’t want.

Large problems and challenges should be broken down into smaller ones.

We learn from small changes. Small repetitive cycles grow the product and constantly improve it

The tools we choose to design with dramatically affect our processes, so select them wisely. Change tools when needed. Use tools in ways they were intended, or in ways that suit you. Choose the simplest tools, or invent your own.

It is possible to seek out data that can be quantified in addition to data that cannot. Both kinds of data contribute to a more complete understanding of your design’s impact.

Greater team and customer satisfaction is improved by constant design-test-release-evaluate-learn-and-repeat cycles.