88 posts categorized "User Experience"

The Most Abused Word in Product Design

Product. That’s the single most abused word in Product Design.

Products are things that are manufactured for sale, and must be purchasable. The buyer will likely have access to it after they’ve paid for it. 

It’s that simple, and that complicated for today's designers. The word Product has become a portmanteau for the following: Physical products, Internet-connected things, consumable packaged goods, software applications, digital services and platforms, real-world services and experiences, and anything else that can be made and sold which won’t fit into the previous categories.

Applying design to a broader range of things we use in the world—that’s often good for both customers and businesses. However, that’s not so good for those who have decided on a whim to update their title on LinkedIn to read Product Designer. It's also not so good for hiring managers who want job titles to have Product in it. We are seeing this play out in weird job titles and job descriptions, probably written by people who don’t realize they’re compounding the issue: 

  • Visual Design/Product Design Manager (actually UI Design in Scrum/Agile)
  • Senior Product Designer-Visual (also UI Design)
  • UX Product Designer (pure UX/UI Design)
  • Head of Product Design & Development (Industrial Design and Physical Product Development)

And I just looked at the first scroll of a set of job listings.

It’s appropriate to say that your company makes products, and that you have a VP of Product, and that thing that you sell isn’t an old-fashioned manufactured physical product. The writer of an article I read yesterday in the New Yorker went so far as to call an LED product a “product-as-service” because the word Product didn’t really do justice to something that you would lease. (That was thoughtful.) 

So, here's my advice. Be cautious about saying that if you’re working on anything that can be sold, you’re automagically a Product Designer. Because if you say you’re doing Product Design, you’d better nail the basics. A Product Designer should be adept at identifying customer problems (“jobs”), as well as formulating and testing product assumptions and hypotheses around what solutions will help people achieve those jobs. Whenever possible, this should be happening through well-constructed experiments.

When I see work from a Product Designer and they are not doing the above things—or worse, they are not even aware that these are things that Product Designers are supposed to do—we are creating a new set of problems for design organizations, and a new set of demands that design education needs to snap to attention and fulfill. Product Design may require tools and skills that aren't always emphasized in Industrial Design or Graphic Design or UX Design or Interaction Design or Service Design or any of the other flavors that are in the Skittles grab bag of design education. Since the word Product has been so heavily diluted, a Product Designer may need to exercise skills drawn from any of those disciplines depending on the kinds of customer problems they are trying to solve—plus Product Design basics.

It’s unlikely that we can stop this Product Big Bang. But what we can do is be more precise about what we expect from designers, and designers can be more thoughtful about how they want to represent their skills when working on products.

So, what’s the second most abused word in Product Design?

The Designer’s Bias

A few years ago, I saw a presentation from a creative director about how he helped brand an experimental elementary school. Before he shared his work, he said: “We promoted the school through videos on YouTube. My first job was as a filmmaker, so every time I see a problem, I want to solve it with a film.”

Since then, I’ve heard hundreds of people make the same kind of statement in everyday conversation: “I’m an engineer, so every problem can be solved with software… I’m an architect, so every problem can be solved with a building… I’m a carpenter, so every problem can be solved with a table.”

There’s a bias operating here. Let’s sum it up as: Every problem I encounter can be solved with things I have the training and skills to make.

Biases are neither good nor bad. They simply are. But we need to acknowledge our biases explicitly if we want to create our best work as designers.

There’s good reason for this. Go back to the statement above, about the carpenter. Let’s not treat it as a joke. Let’s play it out.

Give a carpenter a problem, and the solution will probably contain wood, concrete, or other forms of joinery. The tools she has available will be biased towards working with those materials: pencils and levels, hammers and nails, saws and glue. If she’s an apprentice, she’ll shadow other carpenters as they solve problems and craft solutions. If she isn’t capable of solving a problem on her own, she’ll reach out to people that have the appropriate skills to help.

It’s unlikely you are going to ask a carpenter to solve the problem of how to remove kidney stones with a new treatment technology, or create the next big smartphone, or increase the number of conversions for your large-scale e-commerce website. And yet this happens with designers every day.

As human beings, we get into trouble when we don’t notice how our biases influence our decision making. And designers aren’t immune to this. We’re biased towards solutions we have the skills and means to materially create. We’re biased by the tools we have at our disposal. We’re biased by our schooling and our apprenticeships in the working world. We’re biased by the communities of practice we build up around ourselves. And we’ve invited in an additional layer of bias that is unique to design—that applying the design process to problems large and small is a primary way of creating positive change in the world.

I’ve seen these biases crop up in recent work I’ve seen by design students that are fresh to the profession, by designers in professional practice, by design leaders at startups large and small, in speeches by thought leaders and government officials and people in positions of influence. Most disheartening though, was that these designers were surprised when I asked them very basic questions about how they acknowledge their bias as designers.

If we are being strategic about doing design, we bring our bias into the work because it’s what needed to look at things from a different perspective. But we have to call out what those biases are, both in how we see the world and in the work itself. We need our collaborators to help us acknowledge our biases as designers. In return, we can acknowledge theirs, and build on that understanding to make better decisions.

Designers may be well suited to facilitate the necessary problem-solving work with teams, but we aren’t the only people capable of doing it. Designers don’t “own” problem solving. We make a set of tools available that people can bring to bear on problems, if they know how to use them. Besides, not every problem can be solved by design alone. In fact, if you’re going to try and influence a really big problem, you need more than just design skills. In our work with collaborators from other disciplines, we need to be doing a better job of leveraging this truth.

Otherwise, we will be living our own joke: “I’m a designer, so every problem can be solved with design… Every problem can be solved with a thing that can be designed… Every problem can be solved via the design process… Wait, exactly what problem are we trying to solve?”

Data Doesn’t Tell Stories, People Do

Once Upon a Time Chart

Many years ago, I was interviewing a portfolio manager about how he uses financial information. He said something that has resonated with me to this day: “Every number that I include in my quarterly reports to clients has a story behind it. I won’t meet with my clients until I know what that story is—no matter whether it’s good or bad about their portfolio’s performance. Otherwise, they’re going to bring their own story to it.”

It’s a common error of judgment for designers to assume they know what stories will be told from data. We create donut charts and graphs and tables and many other sorts of data visualization that are meant to communicate particular meanings. 

But data doesn’t tell stories. People do. 

Ask yourself: “What stories do you think people will bring to the data?” Take your designs with real data in place—if legally allowable—and see if the story in your head and the story that your users tell you are the same. 

You’ll always be surprised at what you discover.

Designing for Positive Behaviors and Habits

At sunset, the lingering light painted a neon red line above rolling hills. As I drove north on Highway 101 at 70 miles per hour, the landscape scrolled in parallax, the road receding into night. Up ahead, I could see a white car moving much slower than the speed limit, drifting from the righthand lane into mine. In moments, I would either be passing this car, or it would be crashing into me.

So what did I do? I honked right before I was about to pass. And as I motored past, I quickly glanced over my shoulder to see why this driver was behaving so erratically. The driver’s face was illuminated by the blue-bright glow of her phone in her left hand.

What would possess someone to take this safety risk? Think about how you first learned to drive a car. Maybe you sat in a classroom, listened to lectures, took tests and read manuals. Then you sat inside a car with an instructor, and you stop-start-stopped your way through the obstacle course/parking lot. If you took driver’s ed in school like I did, you may have had a practice car with dual controls, and the teacher would brake for you if you were about to take out yet another orange cone. With the right nudges and active guidance over time, you were able make your way through the obstacle course, drive a few miles in white-knuckled terror on the freeway and maybe even parallel park.

Now flash forward a few years. You’re late to work, so you grab your mug from the coffee maker and run to the garage. Tossing back a big gulp, you back out while pulling on your safety belt, managing the steering wheel with your left leg without thinking while you’re trying to Bluetooth sync your phone to the car stereo so you can listen to a podcast. What was once a hard fought-skill had become an autonomous behavior, which was now layered on top of many other behaviors, often in direct conflict with each other.

Human beings are pattern-making machines. From our first moments in this world until we die, we manifest particular actions in reaction to some form of stimulus or trigger. Sometimes this happens with conscious intent, but much of the time it isn’t.

As interaction designers creating software that can be used at any time in any place, we’re seeing that our products are more tightly wedded to people’s daily behavior than we might have anticipated. Through what we design, we aren’t just creating new capabilities and capacities for people to achieve what they want to accomplish. We are also encouraging new, unintentional habits and patterns of behavior that can have long-term, sustained effects. And few of us have had the formal training to do this in a responsible way.

It’s only the past few years that dialogue about this topic has become common across the product and service design community. Just off the top of my head, I’m thinking of B.J. Fogg at Stanford for his critical research into behavior design and for his instruction of multiple generations of product designers on how to approach this topic and Stephen Anderson for his cataloguing and evangelism of the use of persuasive design techniques. Then we’ve got Chris Nodder’s work showing us the “evil” persuasive techniques that companies use and the work of Nir Eyal, who boiled down all of the above plus many other resources into a digestible book and practice-focused model.

There are many more books, articles, videos, and research in the wild about habit formation, persuasive design and so forth. Some are good, and many of them are great. These people have been researching this topic for a very long time, and there’s a lot to gain from their effort.

In my work as a product and service designer, I’ve had a chance to try out the different methods and techniques that they propose. What I’ve found is that while they have helped my teams think through the mechanics of individual interactions as part of a product, there aren’t a lot of good tools that help with big-picture thinking about what constitutes positive behavior change, and how to collaborate with your users in responsible ways to design appropriate solutions.

In the above talk from HOW Interactive Design Conference, I answered two questions I’ve heard over the past few years from many designers:

  • How can I work as an interactive designer creating products and services that make people’s lives better?
  • Where should I start if I want to make a product for positive good?

In the talk, I shared a three-step process that I developed to stand up the first iteration of a product or service that’s intended to encourage positive behaviors and habit formation. In the coming months, I'll delve more deeply into the details of the above process. Here's a high-level summary of each phase.


1. Defining the promise of your product

When working with a client, it can be easy to use different techniques to encourage habit or behavior formation, without being able to qualify exactly why that habit or behavior is desired by a person and beneficial for them in the long term. People use products and services because they want to accomplish a certain goal for particular motivations that may not be clear you as a designer. Many of the goals people want to accomplish—losing weight, saving money, stopping addiction, and so forth—require multiple habits be put in place and sustained not for a day, or a month, but a lifetime to achieve a desired systemic effect.

At the start of the design process, you want to clarify what type of net benefit a person is looking to achieve from your solution, and how that solution relates to larger societal issues. This net benefit, which is the promise of your product or service, is your hypothesis for how people may value its use as part of their everyday lives.


2. Generating a behavioral vocabulary

When I’m moving through the first iteration of a product or a feature that’s focused on behavior change, I ask my team to determine the vocabulary at play. We identify what people are doing (specific verbs), the objects within the interactive system being acted on or changed (specific nouns), and how those actions add up over time to create or reinforce a particular behavior. These behavioral “chunks” are the building blocks of your product or service. This can be part of your immersion as a team before you do formal research and design.


3. Testing behavioral routines that encourage positive habit formation

Once you’ve established the baseline vocabulary for your potential product or service, it can be tempting to just create and ship something big to get feedback for an entire routine or a systematic set of behaviors. “We want to help people lose weight, so let’s make an app where you get a push notification whenever you’re about to eat a meal to make sure you eat less, then you take a photo of what you’re going to eat, then you write after the meal how much you ate, so that way you end up eating less, and then…”

This is dangerous thinking for any designer. You have to curb this impulse and start by designing for the smallest units of behavior possible, the tiniest habit that could potentially changed, and then see how that change may impact a person’s overall behavior (with their permission, of course). As an example: When designing a solution to help people better save and spend their money, my team spent time interviewing people with different spending and savings behaviors. The first part of each interview was for us to understand their existing savings and spending patterns, and the motivations regarding why they were able or unable to meet their personal goals around saving money. Then, based on the stories they shared with us about when they had struggled to save money, we provided potential solutions to gauge if the vocabulary of the solution fit their needs. If it didn’t, we collaborated with the person to revise the hypothetical solution based on what they thought would be best for them for discrete situations.

“Small wins are a steady application of a small advantage,” says Charles Duhigg, author of The Power Of Habit: Why We Do What We Do In Life And Business. Once you have enough feedback to gauge initial fit for a solution, you can put that increment of the product to a test. I like to start with solutions at the lowest fidelity possible. Instead of creating a software prototype, we might write out instructions for a person to follow on a sheet of paper, then have them snap a photo and send it to us. Or we might manually send a text message or an email to prompt a certain action instead of doing it through an automated service. Once you see how long a habit takes to form, you can think about how to sustain them and whether they can become long-term behaviors. You may also discover that how people use your solution inspires a different, more effective way to form a habit. This helps you better refocus and improve your product or service solution and build it out.


Building New Habits and Behaviors into How We Work

We are heading towards a new destination as designers, collaborating with many disciplines to create the future of almost any digital or physical device we can imagine. And unlike when I was learning to drive my car, there’s little habit-related support for me for me with all of these new and constantly changing products. My teacher can’t remotely stop me from texting during an important meeting and there’s no guidebook to remind me to shut off Facebook in the middle of dinner. Much of the effort is on us, both as the creators and users of interactive products, to integrate new habits and behaviors into how we work, asking the right questions that respect others and what they want to achieve. It’s my hope that a process like this will help make that possible.

An early version of this essay appeared on HOW Design.

Pick a Number, Any Number—As Long As It’s Five

Five out of Five

The car saleswoman leaned over the desk, placed a sheet of paper down in front of us. “This is a version of the customer satisfaction survey they’re going to send you next week in the mail.” It was a garden-variety survey about the car purchasing process, with a five-point scale that ranged from Excellent (5) to Poor (1). She plucked a pen from the desk before her, then drew a hard blue line down the page between the 4 and the 5.

“If I’m rated anything less than a five,” she said, “then I’m not doing a good job. It’s either a five or I’ve failed.” She continued to describe how even one 3 or 4 in a month could lead to her not being considered a top salesperson. Then she wouldn’t be able to take her family to Hawaii or the Bahamas at the end of the year, courtesy of the car manufacturer, as a thank you for her performance.

Talking about the whole situation after dinner, my wife Mary said:

Buying a car sucks. Everyone knows it. There’s no way in hell this survey thing is working. If they’re all getting fives and the company says less than five is a failure, then why does buying a car still suck? These surveys send employees to Hawaii—they aren’t actually influencing the overall customer experience.

Surveys can be useful instruments for gathering data from people, but survey questions can be bent or manipulated in ways that destroy their benefit for everyone. In the end, is anyone actually using this data to improve customer service? Or are they just using it to punish service providers?

Rather than relying on the illusory difference between a 4.5 and a 4.7* for quality service, I’m more interested in how someone answers the following simple question: “Was this service great? Yes or no, then tell us why.” In the case of car surveys, this type of open-ended question is one of the few places post-purchase where direct service improvements are solicited. Matt Jones at Edumunds says “at the end of Customer Satisfaction Index (CSI) surveys, there is a comment section for the car shopper to address any concerns that may have come up while doing the deal. These comments do not affect the overall scoring of the salesperson. If a car shopper thought the music was too loud in the dealership, for example, saying that in the survey comment would likely be a better option than giving the salesperson an 8.”

So next time you think about using a graduated scale in your survey, know why you’re using it, what biases those delivering the survey may introduce, and whether there might be a better research instrument to achieve a more relevant result.

* We see this in services like Uber, where if a driver's rating dips below 4.X stars they may not be able to participate in the service. Absolute perfection required.

Three Engineering Acronyms Every UX Designer Should Know


How DRY is your design? Does every element in your design have CRUD? Can you narrow the GIGO gap?

I find it hard to think about creating UX designs without considering the underlying logic an engineer will use to bring it to life. Successful UX designers are often trained in markup and coding, working within modern web design principles supported by constantly updated libraries housed on Github. However, there are many principles that are used by software engineers that can help new user experience professionals make design decisions that are more likely to be implemented successfully and scale appropriately. Here are three that I use regularly in working with my design teams. 


Just How DRY Is Your Design?

DRY stands for “Don’t Repeat Yourself,” and it’s an engineering mantra every designer should know. “We’ve got to DRY this out,” I’ve heard many engineers say when they’re thinking through how to build on-screen components, establish relationships between page templates, refactor how a back-end service should work through an API, structure a database model, set up automated testing protocols, and so forth. (The acronym originates from The Pragmatic Programmer by Andy Hunt and Dave Thomas.)

The DRY principle has equal application for how designers approach what elements they should include in their screen designs. Exploring many divergent potential design ideas is what allows us to create the best concepts to build and test with users. But we often cause issues by varying our designs in ways that require engineers to create multiple and varied instances of the same objects, styles, and screen structures. We burn time managing these details rather than repurposing key elements. In the long term, users can become confused by so much variation in the large and small details of our designs, and we will need to refactor our design and associated code to simplify the experience.

You need exceptional reasons to justify building out so many exceptions for your product. Apply the DRY principle to your UX and development work by asking these questions of your design ideas, as well as when you enter into critique with your team.

Design Pattern Replication: Are there major variations in the design patterns we’re using across screens? If so, should they be made more consistent? This applies to both overall screen templates and layouts, just as much as the design of modules that slot into your screens. As an example: Say that you’ve created a blog template for your corporate web site where you have a specific carousel design for when people upload and display their images for users. On the home page of your corporate web site, you have a completely different carousel design and implementation. Should they be the same design and code base, or different? If so, why? Can you justify the need for a difference, or should you DRY it out?

Screen Templates and Content Relationships: Is the content hierarchy reinforced across different screen templates? Are we creating too many templates, when only one or two would suffice? Are we thinking modularly about what modules and components will inhabit them? Are we presenting the objects in these templates in a constrained way? As an example: If you have eight ways you allow the user to display a text block or image on a screen, you are creating dozens of potential layout issues and exceptions in how those screen templates are engineered. What if you only had six ways to display those items? Four? Two?

Component Reuse: Do these components we’re using on this screen appear anywhere else in the system? If so, are they consistent? If not, should we consider making them global components, which can be reused over and over again? This approach can apply for anything from radio buttons and drop-down menus to navigation and search patterns. This approach also applies to how you size and present those components across devices, if you’re reinforcing cross-screen consistency and/or fleshing out a responsive design.

Type Handling: Are our decisions around type handling consistent across screens? Do our h1, h2, h3, and other elements match in size, weight, and spacing? Do the typefaces that we’ve selected render appropriately across the devices that we’re targeting? 

Color Use and Reinforcement: Are we repeatedly selecting and applying our color choices in a way that reinforces specific intents for our users? As an example: You use red as a color for when issues come up during in-line form validation for users looking to sign into your product. Are you sure it’s a good idea to use the same color for headlines on your home page and for buttons asking for you to leave a comment?

If you have a strong brand system and design language in place, it’s easier to answer the above questions and make sure your designs are DRY. If you don’t, then continuing to ask and answer these questions from sprint to sprint will help you drive towards a more explicit design language for your product.


Does Every Element in Your Design Have CRUD?

Most things that we design allow our users to create all sorts of content. But as designers, we often leave out the explicit actions that people need to properly interact with that content. And if we don’t specify these actions in advance, we might risk leaving out critical functionality that makes our interactive websites and products unusable.

 All you need to remember is CRUD: Create, Read, Update, and Delete. The term was first spread widely by James Martin in his book Managing the Data-base Environment. These are the key actions (verbs) that people require when using a software system that involves the creation and management of content that is held in a database. You see this principle applied to all types of software, from managing content in a corporate CMS to allowing user-generated content within a product.

Here’s how each action should be considered in your designs.

Create: Provide people with the ability to add an object into the system, including any key supporting details or metadata that support how it’s read and updated. As an obvious example: When you use Facebook and want to post to the News Feed, you tap on a button that allows you to create the post and upload it into their system, including text, links, photos, videos, and any associated metadata that’s required to support how that object will render to yourself and other users. The metadata may be explicit, such as time posted to the system or location, or implicit, such as what other friends happen to be near you and also posting. UX designers should have an awareness of all these data elements when they design a flow for content creation within their product or system. 

Read: Allowing people to view this content once they’ve created it. You will need to choose what elements that the user creates will be rendered, and where it appears in the system. The user may need to sort, filter, or adapt the view of that content object to make better sense of it, as well as take other actions related to that content object. As an example: If you’re managing a web storefront, you may create an item for purchase, and the user will need to be able to read information about it in order to buy it, save it to their wish list, and so forth.

Update: Once you’ve put content into the system, you may need to update some of the details associated with it. You may only be able to edit select fields related to that object, depending on the case. As an example: Revising a comment that you have left on a website may only be allowed for 15 minutes after you’ve posted it.

Delete: If you don’t want the object to be within the system anymore, you need the ability to remove it. The challenge from a design and engineering perspective is not only providing the ability to remove it from rendering, but also to consider the cascade effects of that deletion across your entire design and all screen types. Don’t assume that the user deleting the object should cause it to be wiped from the system completely, especially when the deletion has to do with the user’s profile or identity within the system. As an example, if you go to cancel or delete an account, you may want to ask the user if they want the data to be held in case they want to reactivate the account. Doing this absolutely depends on the context of your system! As a sacrificial example: If you’ve created a website that’s meant for secure, anonymous storage of a person’s legal documents, deleting your account might require the destruction of all objects associated with that person based on what you’ve promised to your user.

You’d be shocked how many websites or products build minimum viable products without including one of the above actions, causing major issues along the way.


Can You Narrow the GIGO Gap?

Most people know the term GIGO: Garbage In, Garbage Out. In essence, if you’re bringing garbage into a system that you’ve created, that system will inherit and recombine that garbage, then presenting it to the user as part of what they experience. (Unless we’re talking about the content we see regularly on fail blogs and humor websites.)

As a UX designer, I want to reduce the ratio of garbage coming into the design that could impact the user, both in what is provided by back-end systems and databases in terms of data, and in what design decisions that I am making that enforce the appropriate level of quality for the resulting output. There is always a gap between the two. Narrowing that gap is one of the constant struggles that you will have as a UX designer, and it’s one of the top reasons why a designer’s intent is not realized in a website or a product.

Ask the following questions of your team to try and narrow the GIGO gap.

Database Schema: Do the content elements and functionality shown in your design exist in your system’s database? If so, what is the level of consistency and specificity in how it’s stored? If there are gaps, how hard would it be to add those fields? In doing so, are there larger impacts that you hadn’t considered? New relationships between those data elements? Missing metadata? New models for content relationships?

Content Audit and Quality: How robust is the actual content that is in the system and stored in your database? Does it meet the quality standard that you’ve set in your designs? If not, how much time and effort will it take to improve it? Does that dovetail with how much time it takes to update the database to store those changes?

Back-End Services: Does the way that content and data is served to the user need to change based on what you’ve designed? Does new functionality that you’ve proposed require new services to make them a reality? Is the quality of that service part of the GIGO gap? If the database and content has changed, what will need to be revised to properly consume and serve that content? Are the proper API contracts in place to allow them to be served for use by your user interface?

Front-End Development and UI/UX: What’s the minimum viable functionality and content revision that can create the greatest impact for the user? If a proposed function or type of content isn’t available for a period of time, does removing it degrade or destroy the design solution you’ve set up?

User Feedback and Metrics/Analytics: How does the user give feedback about what they perceive as garbage in the system? How does their feedback dovetail with the overall data and analysis you’re doing about user behavior?

By answering the above questions, you’ll identify the necessary gaps to fill, and be able to prioritize and plan how they can be improved with your teams.


What Engineering Principles Do You Use?

Are you also using engineering principles in your UX design work? Please leave them in the comments, so we can make stronger design solutions and become BFFs with our engineering collaborators.

Thanks to Michael Devin and Matt Conway for discussing the above principles with me over the years and helping me apply them.

My New Role as Director of User Experience at Lynda.com


In the past five years, I have dedicated much of my effort to helping people learn the skills they need to succeed and pursue their passions, both in professional practice at frog, as a teacher at California College of the Arts, and as a writer of design books that encourage learning by doing. That's why I'm excited to announce that today I joined Lynda.com as their Director of User Experience. In my new role at Lynda.com, I am responsible for the design of their product across devices and platforms, leading a team of UX designers that want to help people around the world reach their fullest potential.

If you're like me, Lynda.com has been there for you when you needed it most. At pivotal moments in my career, Lynda.com has provided me with the training that I needed to advance in my career. Lynda.com has been a premier resource for advancing our individual and collective practices as designers, creators, and businesspeople. For this reason, I'm thrilled that I'll be able to collaborate with their team to make it even better. (And if you're passionate about making a difference in the online learning space, you should join me! I am currently hiring a few UX designers and senior UX designers to join our San Francisco office.)

In addition to this, I have other news. Upon leaving frog as a full-time employee, I have been named a frog Fellow. I am humbled to have been chosen for this rare honor, and will continue to advise select social impact, design education, and project-based learning initiatives at frog in the coming year.

Thank you for supporting my efforts for these seven years I've been blogging about design on ChangeOrder, and here's looking forward to many more!

Slides for “Designing for the Internet of Things” at HOW Design Live 2014


We no longer live in a disconnected world. Ubiquitous, flexible communication has become the norm. We are living in huge device ecosystems, whose complexities are increasingly challenging to perceive. At frog, we’re passionate about designing products that are meant to advance the human experience. That’s why we’re excited about helping to shape the future of the Internet of Things (IoT). There are over 200 billion connected devices estimated to be a part of the IoT by 2020. We need to participate in helping to create these next waves of connected devices, bringing our skills as designers to bear on creating meaningful solutions.

At this year’s HOW Design Live, I was able share some of the tools we use to create design solutions for connected devices, in collaboration with Jennifer Dunnam, a senior interaction designer from our New York studio. Our session, entitled “Off the Page, Into the Wild: Designing for the Internet of Things,” was focused around sharing three tools that Jennifer and I use as part of our design work. These tools included mapping out device ecosystems, creating device behaviors, and imagining stories that show these behaviors in the context of people’s lives. We also had a bit of fun with some “IoT theater,” demonstrating how connected devices function with 10 beach balls and some role-playing.

Playing with beach balls to explain how the IoT works

In our talk, we underscored that the most valuable aspect of the IoT is the human element. The IoT today is not just intelligent kegerators and Nest. And it’s more than simply a network of connected objects, or connectivity for connectivity’s sake. The relationships we have with this vast array of soon-to-be-connected objects, and the emotional qualities that we imbue into how these objects converse with us, must be considered and thoughtfully designed around human needs. This is the frontier we are now charting and exploring.

"Micro-Networks Rise" Prediction in frog's 20 Tech Trends for 2013

I'm honored to have been able to contribute one of frog's 20 Tech Trends for 2013, "Micro-Networks Rise":

Micro-networks are intimate communication networks that people form around subjects of interest to them, whether as simple as their love of chocolate or as complicated as a shared passion for creating change in a local community. Most of these micro-networks are private, and rarely visible to the designer or trend-spotter.

These micro-networks have been fostered in local communities via face-to-face conversation or via email and phone, but just-in-time communication tools have allowed the content of these conversations to persist—and store what people are sharing over time. They encourage connection with people that had previously not been able to join those conversations.

Social platforms such as Quora and Facebook have exploited the budding micro-network trend, allowing knowledge to surface from these communities. Platforms such as Neighborland, frog’s Collective Action Toolkit, and Change.org allow micro-networks to gain momentum and grow around desired political and community change.

Identifying micro-networks and ethically researching how people participate in them will be an important part of how we design any product or service that’s meant to collect and share knowledge in 2013. By combining ethnography with an awareness of what people are doing through their micro-networks, we can gain visibility into trends that are happening, but aren’t always in public view. It can also point us to new and growing private communities that help illuminate for us emerging shifts in customer behavior.

Take a look at the whole set of trends above, or download the poster below:

Know Thy User: The Role of Research in Great Interactive Design

At the recent HOW Interactive Design Conference in Washington DC, I gave a presentation called "Know Thy User: The Role of Research in Great Interactive Design." This 30-minute high-level talk was intended to provide conference attendees with repeatable processes that will help them integrate user research into their interactive projects. Other presenters at the conference went more in-depth into some of the methods mentioned in this talk, but I felt that it was important for attendees to understand the role of specific methods and activities within the research process on any design project.

When I started working as an user experience designer, I had a thousand questions about how to conduct research. I was lucky to have great mentors and have the chance to collaborate with outside practitioners on a variety of projects. They helped me learn how to do everything from recruiting people to facilitating activities to understanding how we could make sense of the data we gathered from them.

When I came to frog, I discovered a deep global research practice with many designers and strategists who have helped me become a more rigorous and creative researcher. I now have fewer questions about how to practice user research, so I'm doing my best to return the help I'd received over the years and answer some questions for those who are new to the role of research in interactive design.

A Hummingbird's Perspective

A Hummingbirds Perspective

Sitting on the cabin's deck was like having a front-row seat at a dragstrip. The birds would park themselves on the perches of a bird feeder, seesawing back and forth to take little sips of sugar water. Then, with a snap, their bodies would shift from sitting to hovering and zip into the treeline.

The lavender in the garden sparkled in the afternoon sun. A light wind played over Westcott Bay, rippling tiny flags on sailboats berthed far from shore. Mary and I had planned this week-long summer getaway so I could finish the manuscript for my second book. After lazy mornings tucked under electric blankets in the cabin, we would spend a few hours walking or drive to Friday Harbor, take in brunch, and then I'd settle down to write for the balance of the afternoon and evening.

This continuous display of nature made the writing hard. We had seen the red bird feeder outside the cabin on previous trips, but those had been in late fall or winter. We'd never had a chance to see the hummingbirds during their migration. I don't think I have ever seen so many hummingbirds in one place. For every sentence typed into the computer, it seemed like there was at least one hummingbird finding its way to the feeder or coursing its way around the yard.

We weren't only dazzled by the hummingbirds. We saw large woodpeckers digging into a rotted log, island cats stalking across the asphalt road looped behind a string of summer homes, a herd of deer pacing through the backyard at dusk. Ants thronged around the herb garden. At one point, two deer were fighting about twenty feet away over who would have first dibs on eating from a tasty bush. In another situation, a baby doe fed on grass up to her shoulder, causing me to arrest the clickety-clack of the computer keys to more clearly hear her chew. In all of these cases, our presence was noted with mild disinterest.

None of this would have been visible to me if I hadn't been sitting on a wooden chair in the backyard, every afternoon.


Within two days of our stay, the bird feeder was nearly depleted. Over dinner that night, Mary and I pondered: Do we refill it?

The cabin we were staying at had no Internet. This was intentional, so we could get away from Seattle and find some focus. So Mary had to use her iPhone for some Internet sleuthing, and figure out how to feed the hummingbirds. With additional information, things only became more confusing.

In sifting through the pantry, we found only raw sugar and powdered sugar. Powdered sugar may be the most crack-like delivery mechanism for sucrose imagined by man—just say the words "funnel cake" and you start salivating. But it isn't pure sugar. It has additional corn starch added to reduce caking. Same goes for raw sugar, which has extra iron in it. Hummingbirds can't process these additives. They prefer pure sucrose. Which made us wonder: What had the hummingbirds been eating up to that point? Who was refilling the feeder? Were they slowly killing the birds?

To be safe, we decided to drive to the grocery store before it closed to purchase white sugar. We also cleaned the feeder before refilling it, as anywhere sugar touches can mildew.


These birds didn't need our help. During this time of year, the high temperatures, light breeze, and blooming flowers and trees everywhere must make for an ideal stopover during their commute up the Pacific coast.

I couldn't help but catch the subtle irony of the situation. Here I was, a user experience designer that didn't let the feeder run out and see if the birds would return to the garden without any additional incentive beyond a flower garden. Instead, I didn't want to risk their absence during our final days of the trip. Or, to put it another way: For the first time in my life, I could see this beautiful bird when he was at rest, all day long. Even if his movements distracted me from what I was trying to do.

The substance of our world can be like sugar water in a sealed tube. Our thoughts and emotions circle, dart around it. We stop, reflect, sip through the provided straw. If we stay too long in one place, we often get stuck in thinking it's the only place to find sustenance.

From a hummingbird's perspective, this really isn't a problem. There's no clear reason why I would be there, watching him eat a fraction of the sugar he'll need for a day's flying… other than it's a lovely place to burn your knees on an overheated MacBook Pro.

I'm the one that isn't moving.

Where the Roads Become Rivers

Street, Dhaka

The rules of the road? There are no rules. Riding in a fast-moving car, the freeway is a fat, pulsing vein, and we are but one blood cell swirling through the body called Dhaka.

Oncoming traffic doesn't matter, since we can swerve into whatever lane is free to get there a few seconds faster. Right of way isn't important, because we cut off everyone else indiscriminately—three lanes of road packed five to six vehicles across at any moment with rickshaws, mopeds, cars, buses, compressed natural gas (CNG) taxis.

The man who was helping me find my way around joked that when traffic lights are green, you slow down. When they're yellow, you start to speed up. When they turn red, you drive as fast as you can.


Stuck in Traffic, Dhaka

Sounds of the road: constant staccato horns warning of impending crashes in a language only locals can understand; strains of late afternoon prayer floating from mosques and prayer rooms; constant pinging of rickshaw bells; intense revving of engines when brief stretches of open road present themselves; painful shrieks of car bumpers on speed bumps that materialize from out of nowhere.

The air is thick with exhaust, oil fumes, plumes of dirt. When I blow my nose, the tissue is stained black.


Market on Saturday, Dhaka

If you live in Bangladesh and want robust health services, quality food, access to clean water, careers for those who have gone to university, greater possibilities for entrepreneurship, better schools for your children, you go to Dhaka.

But with the lure of all the benefits the megacity may provide, the costs of gas, food, transportation, and housing are rising on an exponential basis, further deflating the taka, the country's currency. The district around the city proper of Dhaka has seen unparalleled growth over the past decade, doubling its population to over 16 million residents—most moving into the district from rural communities.


On the Road, Dhamrai, Bangladesh

Peering into other cars, I see haphazard crates of chickens and rabbits strutting in straw; families of eight squeezed into a car designed for five; piles of narrow gas tanks in battered two-seaters; businessmen in striped suits behind chipped, tinted windows; military men in green-purple camouflage with rifles lazily pointed towards the sky; an entire backseat piled with mounds of bananas, jackfruit, oranges, and coconut.

But it's the buses that take most of my attention. Their sides look like flayed skin from a running child who tripped and fell on the asphalt. Blue birds painted above a landscape are gouged off. Names of transit companies are ripped away. Bright white, cyan, mustard, and cinnamon hues: fresh coats of paint mask the bruises, but don't make them go away. Men on the roadside wave their hands, they pull up and part with a few hundred taka. The buses fill up until men hang outside open doors, out of open windows, and finally, clamber to the top rather than miss a ride.

The people on the buses look at me as intently as I look at them.


Sorting Trash, Dhaka

Just as there are no rules of the road, there is little clarity around the boundaries that sustain Dhaka. Much as a flooded river may reach its fingers into any embankment that sustains its flow, the city's efficiencies are eroding in ways that defy their design.

My Dhaka friends tell me this means that if there were any form of major disaster, such as an earthquake or a cyclone, the impact on the city would be catastrophic—and not just because of population density. It has to do with what people have designed to survive, rather than what might satisfy long-term plans.

An example from a CTO of a small software company in Dhaka: "Imagine that a textiles factory employs 3,000 people. When they build the factory, the owners don't install a fire exit. There is no one who can force them to do it. An earthquake strikes the city, the building is damaged, and no one can get out."

He lets this hang in the air, with all of its implications.


Girl Wiping Car Window, Dhaka

Children squeeze between the gaps between vehicles, selling the daily news, slices of carrots and cucumber in thin plastic bags, maps, and books. A man with no hands places his arms against our driver's side, peering inside to look at us. Women with hollow-boned faces tap on windows, some holding babies swaddled in their arms: something to eat?

An eight-year-old girl wipes down the windows and headlights of our car with a dirty cloth. "That girl loves what she's doing," a Dhaka resident says from the seat next to me.

"I don't think that's the precise word for it," I say. "Love." Perhaps she does this out of love, I think. The resident considers my words, says the girl likely cleans cars to bring money back to her family, to eat and have a place to sleep on the one day she doesn't have school… if she is able to attend.

The driver gives her 50 taka before the traffic unfurls. She darts to the median strip.


Overpass Under Construction, Dhaka

Dhaka is pocketed with ongoing construction: bypasses, overpasses, buildings, living domiciles, a university campus. Everywhere you look, you see the soon-to-be complete. The gaps are always visible in the city's infrastructure, from transit to banking to telecommunications, and the entrepreneurial are finding ways to fill them.

New services for wiring money to local post offices and bKash (mobile money services) are helping businesses and families better share their money without bank accounts. The availability of WiMax networks around the city provides people access to high-speed Internet without the need for physical wiring.

But on an individual level, the users of these services have to work the systems in order to make the best use of them. Cell phone users have adapted to uneven network coverage by purchasing multiple pay-per-use phones for competing networks. Business automation suffers due to the constant heat, humidity, and lengthy rainy seasons, which destroys technology. Perhaps destroys is not the exact word. Eat might be better. During the monsoon season, consume might even be more appropriate.


Aarong, Dhaka

Dhaka's exponential growth is reflected in the the fierce celebration of Bangla culture both within and outside the city: in its language, poetry, dance, song, clothing, and crafts. Some businesses are built around curating this cultural output, such as Aarong, a chain of stores started by BRAC that brings together high-quality crafts, textiles, clothing, and other goods sourced from villages in Bangladesh. There is value that Aarong creates that could be replicated across other cultural industries, even though the richness of Bangladesh culture outside of Dhaka is what makes such a business model possible.

And a question lingered in my mind afterward for which I couldn't find an answer: How many people living outside Dhaka would be capable of shopping there?


Ekushey Book Fair, Dhaka

My last afternoon in Dhaka, I visit Ekushey Book Fair. It consumes multiple city blocks, runs the entire month of February, and looked to be attended by what I estimated at 50,000 people that single day. How often do you see such a throng rallying around the consumption of any literature, let alone literature only written in Bangla?

Leaving the bookfair, I talk with the software CTO. He asks me: "What was the most powerful observation you've had about Dhaka?"

"Why do you care about what I think about this city?" I say. "I didn't grow up here. I'm not from this culture. Wouldn't someone who's grown up here know it best?"

"You have to be an outsider to have an opinion about Dhaka," he says. "Many of us also moved to Dhaka—we aren't from here. And so much has changed in the past few years, that it's good to see the city through fresh eyes."

I think for a minute. "How small one can feel, in the midst of a city that is so large. Unlike any other city I've been in, you can't wrap your mind around it. And yet, at the same time, you have so much room to create your own path."

"I agree with that," the CTO says. Then he pauses, looks out the window. "But then again, you have to see rural Bangladesh to really understand Dhaka."


Roadway at Dusk, Dhaka

I keep returning to the behavior of a river when I think of my time in Dhaka. It has an ability to cleanse, to sustain, to transmit, and to display unwavering tenacity when dammed away.

I was only able to go a few hours outside Dhaka for a single day, and not far enough to fully escape the influence of the city. But even in those few hours, I was immediately struck by the sun shimmering off lush fields of irrigated rice and corn, expanses of water, the scale and space of the city inverted. All roads in Bangladesh may lead to Dhaka, but not the rivers.

Within inefficient systems are always the seeds of their long-term survival. You just have to grapple with the chaos long enough to sense where they will emerge. With patience, you can see what new channels the river will cut into the landscape, and perhaps follow them. Or, what is often more likely: see if you can divert some of that flow without disrupting the source. And when the monsoons come, you hold on to survive. The cycle continues. Within that optimism is a strength that can't be easily diminished.

I think this is why so many people see such promise in Dhaka's expansion. Standing alone on a dusty road, surrounded by millions of people, I return to the word promise in the same way that my mind returns to the river: the promise of a brighter future, the promise of what might happen tomorrow. Promise is a positive word, swollen with hope the way that the outer district of Dhaka is being flooded with people darting between cars, walking from home to work or school, doing their best in the sweeping current of the history of their rivers—and their country—to put back together what has been broken.

Thinking Outside the Elephant: Part 2

Addo Elephant Park, South Africa

This is the second part of a recap that was written over 51 hours at the HOW Interactive Design Conference, then delivered to attendees as a 45-minute closing talk. Read the first part here.

Now, for those of you that know me, I have a penchant for pushing analogies to their breaking point, until they become so absurd that they start to resemble reality. So I'm going to start visualizing for you what kind of world our elephant lives in, and what might be stressing her at this very moment.

Continue reading "Thinking Outside the Elephant: Part 2" »

Thinking Outside the Elephant: Part 1

This is the first part of a recap that was written over 51 hours at the HOW Interactive Design Conference, then delivered to attendees as a 45-minute closing talk. The second part will appear on Tuesday.

During the first day of the HOW Interactive Design Conference, I was having a conversation with Richard Hassen of To the Point Design Studio about the challenges that designers with deep expertise in print are having adapting their skills to interactive design. He said: "How am I going to bite into the elephant? It's just too big."

I loved his analogy—that acquiring the necessary interactive skills to be successful in our careers was equivalent to chowing down on a elephant, spoonful by spoonful.

What's inside this elephant? Us, of course. Then tools, clients, technologies, frameworks, methods, you name it. And this is a baby elephant, not a full-grown elephant, since interactive design is much younger than the disciplines of industrial and graphic design. (Baby elephants are still heavy, mind you.)

Based on Richard's analogy, I felt obligated to thinking about just what we were trying to eat. What follows are the four top themes from the conference that describe our proverbial elephant, and further thoughts about what forces are being exerted on our baby elephant, out there in the world.

Continue reading "Thinking Outside the Elephant: Part 1" »

Slides from "Information Architecture: Making Information Accessible and Useful"

The above slides are from a talk I just gave at the HOW Interactive Conference in San Francisco on November 2nd, entitled "Information Architecture: Making Information More Accessible and Useful." The talk was about how designers can help people make use of information—both find and act upon it.

The core metaphor of the talk was centered on a recent trip that I took to the SFMOMA to see a career retrospective of Dieter Rams's work, whose ethos of "Less, but better" is a challenge to any designer seeking to create better websites and applications. (Go see this exhibit!)

I re-explore this trip multiple times over the course of the talk, considering the overlap of information in physical and digital systems—and how conceptually we merge them.

From there, I provide best practices and principles for how to approach information architecture and user experience design in a more iterative, agile fashion through in-line prototyping.

The Tipsy Triangle of Software Startupdom

Tipsy Triangle of Design Startupdom

In talking with entrepreneurs of many stripes over the past year, I've heard the following hypnotic refrain repeated over and over again: "If we design a beautiful user experience, we've got what we need to launch a successful business."

Whether uttered by corporate executives or designers fresh out of school, I've been surprised by this near-religious belief that great user experience is the silver bullet that will attract a huge audience base to your company's products or services. Surface solutions trump business plans. To quote Enrique Allen, founding member of The Designer Fund—a community of designers that invest in designer startup founders (of which I’m a member):

“UX can be a 'grabber,' like the shiny materials we buy but then don't end up using after a few days. Without a solid tech and business model 'holder' that provides lasting utility, startups will peak but then crash…”

Yes, to your customers, the user experience (UX) is everything: it's how your product or service is utilized by the world. But if you are a designer trying to create a sustainable business from your product and service ideas, the UX for your product is one important facet of creating a successful business. The user experience you design, the technology selections you make, and the business model you generate: all of these decisions support how you make money from your products and services. They are interrelated, to the point that you can't truly sustain a business in the long term without them all in place.

This may be obvious advice for those who have spent time creating products and services, or worked at a startup before. But for any designer that is looking to jump into the software game and bootstrap their own products or services, closely consider the following perspectives in the early stages of any new business venture.

Continue reading "The Tipsy Triangle of Software Startupdom" »

Slides from "The Language of Interaction"

I was recently invited to deliver a talk at Emily Carr University of Art and Design about what interaction designers do and how interaction design factors into the worlds of design and art.

My talk "The Language of Interaction" (slides above) was my attempt to summarize the critical role that language plays in our efforts as designers and artists. In doing so, I touched upon the three challenges that all designers and artists face in trying to craft interactions:

  • Establishing a vocabulary, which allows you to articulate what discrete points of a systemic problem you may influence
  • Considering what metaphors may aid you in the modelling of an interactive product or service
  • Understanding how we weave together what we've experienced from our interaction with lateral disciplines to become better at practicing interaction design

To illustrate the last point, I created a timeline of my lifelong explorations as a designer and artist, and discussed how I couldn't have been an effective interaction designer without traveling through a range of related (and seemingly unrelated) disciplines. Over time, all of them were threaded together.

Many thanks to Haig Armen and Laura Kozak of Emily Carr, who invited me up to Vancouver, BC for this talk.

When Sparks Won't Fly

Designer Charades

I'm proud to welcome our very first guest columnist. She is a writer, teacher, and public speaking coach, and has been a collaborator for much of the thinking on this blog since its inception. She was also my co-author for the e-book Creative Workshop: Teacher's Guide. Welcome to ChangeOrder the first full post by Mary Paynter Sherwin.

A group of us have a Wednesday night ritual. We sit around at our local burger place and kvetch about work and life and design. Every burger comes with fries, no questions asked. No extra effort. But you can get onion rings, and there’s a Mafia-like dialogue that occurs when orders come around. Onion rings are powerful, because you can get lots of fries for a single ring. We have to make sure that sides of rings and fries are equally distributed. If three of us get onion rings, everyone else has to get fries, or the whole thing goes off kilter. There’s probably a decision tree on some humor website about how this all works.

I’d been obsessing over these onion rings all day long. I hadn’t had them in weeks, and come hell or high water, they were going to be on my plate that night. Our favorite waitress came around to serve drinks, and I ordered first. And ten minutes later, my plate showed up with French fries. Because that’s what I ordered.

Why, after all of that planning and drooling, did I suddenly change my mind? If I really, really wanted onion rings, why didn’t I order them? Everyone else had to pick their fries or onion rings accordingly, based on my preference. A preference that wasn’t really my preference.

I ate an order of French fries because I couldn’t speak the words, “onion rings.”

My brain has electrical problems. From time to time, my ability to speak what’s in my head escapes me. I can see the word “cat,” can look at a cat in a book, and out of my mouth comes “Christmas.” More often than not, nothing comes out at all, and I just sit and wait. Eventually, the right word makes it through the synapses to my mouth. Or it doesn’t, and people think I’m really tired. Or on drugs, a popular theory in high school. Last night, though I was frantically thinking “onion rings,” that was as far as it got.

I’ve had a lot of years to deal with this glitch. And yes, I’ve had a full medical workup and, though it’s pretty clear what’s happening on an EEG, I’m fine. But it wasn’t until last night that I realized how much my inability to communicate about simple and familiar things could influence other people around me. Because I wanted something that I couldn’t articulate, and because I had no way of communicating that failure, everything else changed.

Continue reading "When Sparks Won't Fly" »

Interaction 11 Recap: Thinking on the Outside

Bill Vanderplank

In early February, a number of frogs attended this year's Interaction 11 conference, sponsored by the Interaction Design Association (IxDA). Our time in Boulder began with a fresh blanket of snow and ended with all-you-could-drink absinthe at the closing night party. In my contribution for the conference, I taught a three-hour workshop called "Better Ideas Faster: Effective Brainstorming for Interaction," which focused on the unique tools and techniques that interaction designers bring to bear in translating research findings into actionable design concepts that cohere into large-scale systems.

This year's conference has been hard for me to summarize—not because of the absinthe, mind you—and in combing through my notes and reflecting on the experience, more questions have emerged than coherent themes.

Continue reading "Interaction 11 Recap: Thinking on the Outside" »

The Metaphor of the System, Part 3

Outfit Hierarchy

In Part 1 and Part 2 of this series, I identified the elements that comprise an interaction model: UX patterns, feature clusters, system behavior over time, and UX principles. What sews those elements together is what I had been calling an "interaction metaphor," or the metaphor of the system.

So, how is an interaction metaphor different from the parti, as described in the previous post—the central idea or concept of a system? I'll venture a guess, though this is still rough thinking and confined just to interaction design.

Continue reading "The Metaphor of the System, Part 3" »