“The greatest compliment that was ever paid me was when one asked me what I thought, and attended to my answer.”
— Henry David Thoreau

Getting user feedback is hard.

It’s so hard that companies pay war chests of hard-earned revenue to consulting agencies who wheedle it from their audience. They drag Average Joes into two-way mirror testing chambers, invade their most private social networks and inject popup surveys between them and their content at every permissible opportunity, all in the name of finding out what is meaningful to them.

So, you’d think if there were an abundance of voluntarily-provided feedback, they’d treat it like some kind of godsend and react to it with equal parts compassion and excitement. Instead, we get the modern FAQ page.

I’m just going to come right out and say it – 99% of FAQ pages are built on two kinds of bullshit: lies or laziness.

Let’s set aside the mind-bogglingly inane practice of inventing your own “frequently-asked” questions (the “lies” part) and assume your clientele truly is persistently barraging you with the same set of inquiries, day in and day out.

If people are constantly asking you the same questions, it means two things:

1. These questions are important to your audience, and…
2. Your website is doing a crap job in answering them

Your website’s users don’t want to contact you to get the information they need — that’s why they’re on your website to begin with. For them, reaching out is a last resort. And for each that does, many others won’t even bother.

Of course, we can’t predict every single aspect of an interaction ahead of time and users are bound to surprise us with things we hadn’t planned for. It’s what you do with your post-launch findings that matters, and putting them to applicable use is a golden opportunity for improvement. Shelving them away in a dark corner of your website is not a particularly great way to seize the opportunity, to say the least.

Like your customers’ resistance to reach out, it should also be a last resort for you to create an FAQ page. In most cases it’s a cop-out, a white flag of surrender. Most FAQ pages are basically saying “We give up. There’s no way to design this site to accommodate user needs X, Y and Z — let’s just toss ‘em in a catch-all bin.”

So what can you do instead? Treat user feedback as what it is: a valuable list of potential improvements you need to investigate and, usually, adapt your site around.

Sick of people asking you how much your product costs? Find a way for the website to better answer that question ahead of time. Getting pestered with tedious requests for info already available on the site? Could be time to find ways to surface it using a more resonant language or content structure. Annoyed with all of the questions about how to recover lost passwords? Sounds like the current sign-in component isn’t doing its job.

Your website exists to serve the overlapping needs of the business and its customers. It exists in a continually changing social environment, and that change needs to be met with equally continuous internal calibration. Let’s take every opportunity we can to genuinely attend to the feedback we value, stop guessing at what people might want to know, and start paying attention instead.

“We don’t see things as they are, we see them as we are.” – Anais Nin

I have always thought baby mobiles are designed backwards. Let’s say, for example, we have a very cute and pleasant one with colorful wooden cutouts of bunnies. To the adult who installed it, this looks perfect as it hangs over the crib:

but to the baby (the party this product is supposed to be designed for) it projects a much less interesting visual:

There seems to be a tension here: its purpose is to entertain babies, but it’s positioned to appeal to adults. While having the bunnies face the cognizant, wallet-wielding side of the equation may be the more marketable decision, the baby’s experience is no doubt the poorer for it. In fact, in this particular case their enjoyment of looking at the bunnies is at the direct expense of their child’s ability to do so. The parent feels they’re providing something enjoyable to the baby, but objective observation indicates otherwise.

This tension is no different in the web world than it is in the product world – clients (those with the money) want to receive a website that they like, assuming that that feeling will be mutual amongst their customers (those experiencing it). If we turn the dial too far towards the client, though, we risk providing a spectacular but irrelevant product – a virtual “yes man” of a website, comforting them but not serving their best interests.

In my mind, this is the essential crux of user-centered design: identifying the tradeoffs of catering to either the client or the user, and presenting suggestions for how both parties may best be served.

When in doubt, it seems like the best option is to side with the people actually using it – not only are they the ones it’s presumably supposed to be designed for, but their perspective is also likely to be the least-represented throughout the design phase. Moreover, by serving the users we in fact serve both parties simultaneously: the website is only valuable to the client if it’s creating a real-world effect in behavior, and that can’t happen if it doesn’t resonate with its audience.

You would be hard-pressed to find a parent who would sign off on an instruction like “make this baby toy less interesting to my daughter and more interesting to me”, and yet examples abound, particularly online. The hope of user-centered design is to remind us of our higher ambitions, and remember which way the bunnies should be facing.

Most clients, especially those working with traditional design & marketing agencies, are accustomed to a “waterfall” process, in which their project is handed to a large team and divided into a series of discrete phases such as discovery, design, development, testing, launch, and (with any luck) maintenance.

The waterfall process offers several perceived advantages for both agency and client, however many times those benefits are outweighed by the inherent inflexibility of the system. For instance, once a client has provided sign off on a design layout, any change no matter how small or logical typically triggers a change order and schedule adjustment. This is just one example of the back and forth that naturally occurs with any digital project where the waterfall method is not well poised to respond naturally.

Clients and other project stakeholders may not be able to fully understand how a certain feature will work — or even if that feature is necessary — simply by looking at a wireframe or a design comp. Features can be added in a few minutes of design that can result in days or weeks worth of programming. A seemingly simple content change can have a ripple effect throughout the structure of a site. All of these result in costly changes to the project and timeline.

Just because things have been done a certain way for years doesn’t mean they can’t change, and change quickly.

We believe in a “lean” process in which we work to eliminate wasted time and effort by delivering work for review as quickly as possible, and gathering feedback to incorporate new knowledge into the next iteration of the project.

The leaner we are, the easier it is for us to respond to change. Using smaller, more focused project teams gives us something special: agility. The ability to be nimble and respond quickly and appropriately to change is one thing that small teams have by default that large teams don’t. A change that might take a larger team in a large agency a week to implement might only take a day for a smaller, leaner team to deliver — especially if that team is planning to work that way in the first place.

Iterate quickly. Iterate often. Unlike the waterfall process that requires agencies to “get it right the first time”, an iterative process allows us to get a working piece of functionality in front of actual users as quickly as possible, even if it’s not perfect, and adjust from there. We can quickly gather feedback, determine if we need to make changes to the design or functionality, and create solutions to address any concerns for the next iteration. A great example of a successful iterative process at work is this Nordstrom Innovation Lab case study.

Though this is a challenge to how most agencies approach their work, we believe it is one worth taking on. Just because things have been done a certain way for years doesn’t mean they can’t change, and change quickly. We believe that starting from a goal and working toward a feature, expecting and embracing change along the way, will lead to better outcomes for our clients and ourselves.

“Writing about music is like dancing about architecture.” — Elvis Costello

When the art of cinema was young, it was defined in terms of other preexisting art forms – “music of light”, “painting in movement”, “architecture in motion”, and so on. This was reasonable, considering it was in its infancy and its true identity was still emerging. Like any new medium (early television was called “radio with pictures”), the internet has gone through a similar process of self-discovery.

Much like cinema initially referenced the traditional form of theatre before coming into its own, web design has always borrowed heavily from the more established print design world, replicating its values and limitations alike – essentially considering websites to be “documents with clicking”.

However, interactive experiences are terrifically complex and richly nuanced, and crafting the means for such an experience is a tall task. Outside of some documentation remnants of a UX/planning stage, nearly every step of the average site design process (wireframes, roughs, comps, revisions, etc.) concentrates primarily on documenting how the website is presented under a number of different conditions.

Relying on the visual design to do the heavy lifting of the creation process is a problem because most of the non-visual thinking is lost as soon as the layout is handed to a collaborator, leaving them to guess at the intent behind the decisions made. It shows, but often doesn’t tell.

As in the quote at the top, “dancing about architecture” is not the most natural endeavor, and it’s time we questioned whether “compositioning about websites” is either.

Just as cinema went on to attain its unique identity after its basis in replicating theatre, if we peer beyond the graphical aspects of websites that are most readily familiar to us we can see the emerging identity of web design: interaction.

If instead of focusing the project around its layout we all focus on defining and facilitating the behaviors we want that layout to elicit, the project’s conceptual integrity is shared rather than left to interpretation. With a blueprint of behaviors directing not only the visual but also structural and interactive elements, every discipline involved can do their best work without any loss of information along the way, including after launch. This opens up the opportunity to better collaborate across roles, teams and even time.

Websites exist to solve problems – to spread information, to forge relationships, to help people do things they could never have imagined before. As such, the essence of web design lies less in the pixels and content on the screen and more in the real-world human behaviors it facilitates. Shifting our focus from the design of documents to the design of interactions frees us from our commitment to defining a website by its material form and gives us the ability to define a website by what it can and should be: experiences with purpose.

Design the interaction, and the rest will follow. After all, websites don’t even really exist unless they’re used: it isn’t just what it looks like, it’s what it does.

We are rich with theories and hard at work in finding what’s possible in this approach, and we welcome you to join us.

Gut feelings are locked away in a part of the brain that doesn’t have access to language and most attempts to justify or explain them only result in a story spun for ourselves or others to believe. This presents an obvious problem for us as makers when creating a digital project: guidance and feedback can be difficult to provide or receive without resorting to opinion, making it very difficult not only to determine the success of a project, but also to plot a course for success in the first place.

By outlining a series of goals to build on rather than a list of things to build, it’s much easier to determine whether or not an idea will contribute to a project’s success.

How many times have you scheduled a visit to the doctor armed with a well intentioned list of suggestions to solve your problem based on a bit of googling? That’s not much different than hiring an agency to build your website and coming in the door with a list of features; in both cases the expert is being asked to fill a prescription without a full understanding of the problem.

Unfortunately, most projects that begin with this foundation don’t end with a sustainable, measurable outcome that justifies the investment required to create them. After years of experiencing various sides of this arrangement, we’ve shifted our approach from planning the “what” to understanding the “why”, from the features of a project to the goals behind it.

We’ve found that by first outlining a series of goals to build on rather than a list of things to build it is much easier to determine whether or not an idea will contribute to a project’s success. When a feature has to support a business or behavioral goal in order to make the cut, the inevitably varying opinions guiding a project are also forced to align behind a common standard of qualification. This makes actively seeking the simplest and most intuitive solutions to the problems we’re being hired to solve a much clearer process, and though it eventually results in a list of components to build, both we and our client can be confident that we’re on the right track.

Another strength offered by shifting from features to goals is the ability to intelligently correct course after launch. While many projects end with a “post mortem” phase where everyone considers what went well or could have gone better, the last thing we’d call the launch of any digital project would be its death. Unlike a magazine or poster, digital work can be measured and adapted for the better after it’s launched based on real data.

Even after establishing goals and building only the features that support them, the launch of a project is still essentially a best guess at what will succeed. If proper care is taken to set the right goals and build around them, the launch of a project is the first opportunity to take actual usage data and further align the features behind the goals. For instance, if users are frequently searching for a certain type of content, that’s an opportunity to address the site’s content structure. If a certain product or workflow isn’t converting to sales, there’s an opportunity to run some A/B tests to increase conversions.

Figuring any of that out and making the necessary changes requires a solid foundation of clear goals at the outset and follow through after launch. This may seem like common sense, but it’s not so common in our industry and it’s time for that to change.