Posts Tagged ‘UX Design’

Interaction Design Tactics For Visual Designers

09 Sep


Anyone designing Web-based properties today requires a basic understanding of interaction design principles. Even if your training is not formally in human-computer interaction, user experience design or human factors, knowing the fundamentals of these disciplines greatly enhances the chances of your design’s success. This is especially true for visual designers. Many visual designers are formally trained in art school and informally trained at interactive agencies.

While these institutions focus on designing communications, neither typically provides a strong interaction design foundation. Having a broader skill set not only makes your designs more successful but makes you more valuable and employable (i.e. you become the unicorn). While in no way exhaustive, to get you started, here are five key tactics to understand and implement in your next project.

A Graphic Designed Sculpture
Image credit: Kristian Bjornard

1. Talk To Your Customers

The most important thing to understand when designing an online experience is your audience. Understanding who they are, what they do for a living, how old they are, how they work, what they know about the Web, how they use it, on what devices, where and so on provides invaluable insight into their pain points that you are out to solve.

Setting clear constraints on your design also helps. For example, if your audience will predominantly be using mobile devices to access the Web in hospitals, then your design must be responsive to those devices and be compatible with the environments where the devices will be used. In addition, understanding your audience builds on a communication design foundation by revealing your users’ sensitivities (physical or cultural, for example) to things like color and typography.

Understanding your audience requires conversation with target users. These conversations can happen in a variety of forums. While impersonal approaches such as surveys work well enough, nothing beats face-to-face conversations with your customers. Depending on who you’re targeting with your work, finding your target audience may be as simple as going down to the local coffee shop, buying a handful of $5 gift cards and striking up conversations with the patrons there. Most people will gladly exchange 10 to 15 minutes of sharing their opinion for a coffee shop gift card. Other ways to find users are to post ads on websites like Craigslist, pull names off your customer lists, reach out to trade organizations (for specific user types, like nurses) and spend time in locations where your audience spends time (for example, music fans at a concert).

The initial conversations will be awkward, but as more and more take place, a rhythm develops to the questions. Also, patterns begin to emerge, allowing you to tailor the questions more appropriately with each interview. The lessons you take away from these activities can be used to create personas — i.e. aggregate representations of typical users of your design — that can help provide context to future design decisions.

A persona document. (Image: Todd Zaki Warfel)

2. Orient The User

Now that you’ve got an understanding of who your user is, orienting them when they use your design is important. Orienting your users gives them a sense of place in a non-static experience. To effectively provide that sense, your design should tell users three things:

  1. Where they are
    Critical to any online experience is understanding where, in the broader context of the website, the user is currently transacting. If it’s clear to the user where they are, then there is a greater chance they’ll understand what you need them to do on that page. For example, if the user is aware they are on a “product page,” they should expect to see a purchase link and perhaps some other product options.
  2. How they got there
    If providing clarity on the user’s current location provides context for expected actions, then showing them the path they took to get there provides a safety net. That safety net is the comfort of knowing that if the user has wound up in the wrong place, they can back out and try again.
  3. Where they can go from here
    You’ve made it clear where they are and how they got there; if they are in the wrong spot they can backtrack and try another path. But if they’re ready to move forward or they believe the path back won’t provide the content they desire, then letting your users know what options are available from this point on is imperative. Never leave a user in a dead end. There should always be an option to proceed. A perfect example of this is a search results page that yields no results. While you should let the user know that nothing matches their search query, there should be options that lead them to the answers they seek (for example, related search terms). Ways forward can be manifested in your website’s navigation but can also be implemented as affordances. Affordances are elements in the interface that are obviously clickable, such as buttons and sliders.

Amazon no results page
Amazon does a good job with its no-results page.

(For a great primer on affordances, pick up Don Norman’s The Design of Everyday Things. While a bit dated, it lays a solid foundation for how product designers should think about their products.)

Clear website orientation provides comfort to users. It also reduces the chances that users will make mistakes and increases the chances that, when they do, they’ll be able to recover quickly.

3. Simpler Is Better

Visual designers are driven to add elements to a layout that may be aesthetically pleasing but don’t necessarily serve an interaction purpose. While certainly much is to be said for aesthetics adding to the polish and feel of an experience, when designing an interactive experience, consider opting for simpler design. Simplification means reducing the elements on the screen down to the most basic ones, the ones that will facilitate the task that the user has to complete. Start with that as a baseline, and then add ornamentation sparingly. Consider the brand of the website. The brand is a reflection not only of the aesthetic but of the experience. If a website is gorgeous, but its beauty makes completing a transaction impossible, then the website (and brand) will ultimately fail.

Aesthetics will always have a place and powerful purpose in any experience, yet ensuring that the experience is usable first is critical.

4. Design For A Dialog

Where visual design training focuses primarily on communication, interaction design puts a heavy focus on feedback loops — in essence, a conversation between the user and the website. As you work out an experience, provide ways for the system to communicate back to the user when they’ve done something right or wrong. Ensure that your experience makes clear when the user has succeeded and when an action is required to complete a transaction. Use your visual design and communication skills to build a visual language for this feedback dialogue. Ensure that no matter where the user is in the experience, any information that is coming from the website is consistent in design and presentation method. Different types of information will require different treatments. The user will learn the system quickly, and a dialogue with the website will begin to occur. In essence, you’re humanizing the experience (and the company behind it) by proactively predicting your users’ needs and presenting information and actions that mitigate user frustration.

Think Vitamin
Think Vitamin keeps the conversation going with its readers.

5. Workflow: Understanding The Before And After

Visual design is beautiful. It’s also static. Interaction design builds a workflow from page to page and from state to state. As you design each page, consider what the user can do on this page and how the next step in the process fits into the workflow. If you’ve just added a sign-up form to the page, think about what will happen when the user presses the “Submit” button. Will the page refresh? Will there be a confirmation page? What if there are errors in the form? What if the user hits the “Back” button? These are all components of the workflow of the experience. Each page or state is just one small component in the user’s click stream. The challenge is that each user might have a relatively unique click stream, depending on how they got to your website and why they came. You’ve used your knowledge of the user to orient them, and you’ve provided a simple interface that creates a successful dialogue with them: now ensure that each interaction has a logical next step. That next step should fit into the experience and visual language that you’ve created, so that the experience feels whole and consistent. These elements are what add credibility to the brand and increase users’ trust in your design.

Bonus Tip: Understand Your “Materials”

Jonathan Ive, designer of the iPod (among other things), promotes the idea that designers of all types must understand the material they’re working with. This hold true for interaction design as well. Understanding the “materials” that make up the Web is critical. A cursory education in HTML, CSS, JavaScript and related technologies will only enhance your understanding of the medium and provide a realistic perspective on your designs. A great resource for this is the group of developers who will be implementing your work. Strike up regular conversations with them about your design, and get a taste of whether your proposals are feasible given the technologies they employ. Even better, start learning the basics yourself. You don’t have to become a star coder, but knowing enough about how the medium in which you work behaves can greatly shape the interactions you design.


Interaction design is a multi-faceted discipline that links static communications together to form an experience. Understanding the basic principles of this discipline is core to designing websites that are not only aesthetically pleasing but that actually solve business problems and bring delight to their users. This article just scratches the surface of interaction design. For Web designers of any kind, considering these fundamentals when designing any transaction or interaction is imperative.


© Jeff Gothelf for Smashing Magazine, 2011.


Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

30 Aug

Advertisement in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation
 in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation  in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation  in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

No man is an island entire of itself; every man is a piece of the continent, a part of the main…

– John Donne

If you’ve ever worked at a company of any size, you’ve experienced it. Isolation. That feeling of being utterly alone in what you do.

Some people love it: the determination that comes from being a lone ranger, boldly going where no one has gone before. Others hate it: the despair that comes from slaving over a design only to see it disappear down a black hole of development, whereupon it emerges onto a website months later, unrecognizable from the pixels you put on the page with such painful precision.

Island in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation
Image credit: Ibrahim Iujaz

These are the perils of working in siloed environments, and it’s where many of us find ourselves today. We’re either terribly alone or terribly frustrated, depending on the particular variety of silo we find ourselves in. In this two-part series, I’ll explore the consequences of working in isolated environments, and how we can solve this problem by encouraging more collaborative cultures.

What Exactly Are We Talking About Here?

Silos in work environments usually come in two flavors:

  1. Lonely silos
    Lonely silos are made up of workers with no real connection to the outside world. This often happens at start-ups where the focus is more on getting something out the door than on doing it right. I mean, who has time for proper UX design when “we’re building [technology x] because [company y] hasn’t built it and [people z] need it?” (as Kyle Neath recently put it).
  2. Functional silos
    Functional silos feature workers who may be part of fantastic design teams. They have great whiteboard sessions, help each other out, enjoy their pizza Fridays… And yet, they have no real seat at the table when it comes to business strategy. Design happens painfully slow because it has to be signed off by 10 different people. And even then, there’s no guarantee that anything will be implemented the way the designers envisioned it.

Working in lonely silos and functional silos have two main consequences, both devastating to software development:

  1. No process
    This usually happens in lonely silos. It’s everyone for themselves. The company subscribes to the “release early, release often” approach, and so you won’t get bogged down with a formal development process, guidelines for functional specs or any of the stuff that big lame corporations busy themselves with.
  2. Too much process
    This usually occurs when functional silos get out of control. Organizations resort to putting hierarchies and processes in place to stop the “cowboy coding” madness. The science:art ratio in design shifts way too much to one side or the other. Functional specifications move into Microsoft Word templates that are 20 pages long before a single word of content is written. And sure enough, the cowboy madness stops. But it gets replaced with a different kind of madness: stagnation.

The Consequences Of Not Following A Design Or Development Process

When you work in an environment where silos result in no clear design or development process, the following often happens.

1. MVP Madness

We all know the concept of “Minimum Viable Product,” but revisiting Eric Reis’ definition would be useful:

The minimum viable product is that product which has just those features (and no more) that allow you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

Problem is, that last section of the definition often gets ignored. You know, the part about people paying you money. So this MVP idea can be taken too far, and a product can be released before there is a minimum viable understanding of what the thing is supposed to do (or who it’s supposed to be useful for). You could argue that the Color app is an example of this MVP madness (“It’s a photo app!” “No, it’s a data-mining app!” “Actually, it’s a local group-messaging search/recommendations app!”)

Perhaps the best example of this culture is the Lifepath sign-up page, which Dustin Curtis recently put up in what I’d like to believe is a deliberate and very effective attempt at MVP irony:

Lifepath1 in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation
Lifepath sign-up page

A lot of this problem would go away if we evolve MVP thinking into what Andrew Chen calls “Minimum Desirable Product”:

Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users.

I think that definition would send a lot of MVPs back to the drawing board, and rightfully so.

2. No Significant Design Focus

The second consequence of a lack of process, particularly in start-ups, is that design is often the last thing on people’s minds. I recently heard an interview with a start-up founder who gave the following overview of their staff: “We have 13 employees: 9 software developers, 2 sales people, 1 operations manager and a social media conversationalist.”

The company hired a social media conversationalist before it hired a designer. In this type of no-process world, ideas go from vision to code (and users) in one easy step, bypassing the principles of user-centered design completely. As Erika Hall puts it:

The floor of Silicon Valley is littered with the crumbling husks of great ideas — useful products and services that died in the shell before they hatched out of their impenetrable engineering-specified interfaces.

3. Endless Cycles

A third consequence of no-process development is that you never really know when you’re done. Not to make this about methodology, but this is one area where the “definition of done” concept in Scrum is extremely useful. If you don’t know when you’re ready to push something live, then the problems of MVP madness and lack of design are exacerbated.

Google Wave is a case in point. Listen to Douwe Osinga as he gives two good examples of MVPs done right before moving on to the problem with Google Wave:

Thinking big sounds great, but most big ideas start small and go from there. Google itself started from the notion that it would be interesting to look at back links for pages. Twitter started out as hardly more than a group SMS product that also works online. Facebook explicitly restricted themselves at first to one university.

Wave is a case in point. Wave started with some fairly easy to understand ideas about online collaboration and communication. But in order to make it more general and universal, more ideas were added until the entire thing could only be explained in a 90 minute mind blowing demo that left people speechless but a little later wondering what the hell this was for.

The Consequences Of Having Too Much Design/Development Process

So that’s what can happen in a no-process environment. But what happens at the other end of the continuum, where process is king of the world?

1. Org-Structure Design

When you can sketch out an organization’s structure by looking at its home page, chances are it’s hopelessly lost in functional silos. I experienced this first-hand while working at eBay. I would sometimes run into the product manager for the home page in the morning, and he’d have no idea why his page looked the way it did on that particular day. Each day was an adventure to see what had changed on the page that he “owned.”

Don’t believe me? Below is an example of the eBay home page from about a year ago, with the teams responsible for each section of the page overlaid (they’ve since gone through a redesign that fixed this issue):

Ebay-silo in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

This is unfortunately one of the side effects of functional silos. You run the risk of losing any sense of holistic design direction on the website.

2. Design Monkeys

Another consequence of an over-reliance on process is that designers could become nothing more than monkeys, cranking out efficient, perfectly grid-aligned but completely uninspired designs on an assembly line. Wondering whether this is you? Here are some instructions you might recognize as a design monkey:

Pop-1024x88 in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

Web2-0 in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

Comicsans F in Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

Don’t get me wrong: I believe in style guides, and I believe in design constraints. But when an organization becomes overly reliant on design rules, creativity is often the first thing out the door. Yes, design is much more than art (we’ll come back to this later), but it’s certainly not pure science either. Without the right injection of art and creativity, science gets boring and forgotten pretty quickly.

3. Tired Developers

Once process takes over an organization, the acronyms start. And arguably, the most feared of them all is PRD: the product requirements document. This usually takes the form of a Word template, with a two-page table of contents. It includes a solution to every single eventuality the software might ever encounter. It sucks the soul out of product managers and the life out of developers.

To use another example from eBay, we once had a 23-page PRD to make some changes to our SiteCatalyst JavaScript implementation. And then the project didn’t happen. I shudder to think about the hours and hours of lost productivity that went into creating this document that never got used. People could have created things during that time. Instead, they sat in Microsoft Word.

The result? Tired developers. Developers who don’t want to code anymore because coding becomes 70% deciphering Word documents, 20% going back and forth on things that aren’t clear, and 10% actually coding.

How do you know that your developers are tired? Charles Miller’s explanation of what it means when a developer tells you that something is “non-trivial” sums it up pretty well:

It means impossible. Since no engineer is going to admit something is impossible, they use this word instead. When an engineer says something is “non-trivial,” it’s the equivalent of an airline pilot calmly telling you that you might encounter “just a bit of turbulence” as he flies you into a cat 5 hurricane.

Tired developers use the word “non-trivial,” or some variation thereof, a lot more than energized developers.

4. Distrust Between Teams

When people don’t live and breathe each other’s workflows, understanding the decisions they make is hard. And if you don’t understand the reason for someone’s decisions, distrust can creep in.

Functional silos that rely on too much process serve as fertile ground for distrust in relationships. A reliance on process can instill a false sense of security and the mistaken assumption that conversation and understanding are less important than proper documentation. This is particularly true in the complicated relationship between designers and developers. As Don Norman recently put it:

Designers evoke great delight in their work. Engineers provide utilitarian value. My original training was that of an engineer and I, too, produce practical, usable things. The problem is that the very practical, functional things I produce are also boring and ugly. Good designers would never allow boring and ugly to describe their work: they strive to produce delight. But sometimes that delightful result is not very practical, difficult to use and not completely functional. Practical versus delightful: Which do you prefer?

So, when designers and developers are not in the same room from the moment a project kicks off, or when design becomes prescriptive before thorough discussion has taken place and everyone has sweated the details together, the stage is set for the two worlds to collide. Breaking down these silos is the only way to design solutions that are practical and delightful.

5. Design by Committee

Not everyone can code, so they don’t go to developers telling them that their HTML needs to be more semantic. But everyone thinks they’re a designer, or at least has a gut feeling about design. They like certain colors or certain styles, and some people just really hate yellow. Because everyone has an emotional response to design and believes “it’s just like art,” they think they know enough about design to turn those personal preferences into feedback.

One of the first things we need to do to solve this problem is to teach people how to give better design feedback. Mike Monteiro gets to the crux of the issue in “Giving Better Design Feedback”:

First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question.

And how do we respond practically to the problems of design by committee? Smashing Magazine’s own article sums it up best:

The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go.

Here are four principles I use in my day-to-day work to make that statement a reality:

  1. Respond to every piece of feedback.
    This is tiring, but essential. Regardless of how helpful it is, if someone took the time to give you feedback on a design, you need to respond to it.
  2. Note what feedback is being incorporated.
    Be open to good feedback. Don’t let pride get in the way of a design improvement. And let the person know what feedback is being incorporated.
  3. Explain why feedback is not being taken.
    If a particular piece of feedback is not being implemented, don’t just ignore it. Let the person know that you’ve thought about it, and explain the reason for not incorporating that feedback. They will be less likely to get upset at you if you explain clearly why you’re taking the direction you’re taking. And if you’re not sure how to defend the decision…
  4. Use the user experience validation stack.
    Read the post “Winning a User Experience Debate” for more detail. But in short, first try to defend a decision based on user evidence — actual user testing on the product. If that’s not available, go to Google and find user research that backs up the decision. In the absence of that, go back to design theory to explain your direction.

Summary, And Where We Go From Here

Ending an article on such a doom-and-gloom note feels a bit wrong. But maybe pausing here would be good so that we can all reflect on the issues that siloed development creates in our own organizations. As UX people, we’re taught to understand the problem first before trying to solve it, right? So, let’s do that. Did I miss any consequences? Anything you’d like to add or challenge about the consequences I’ve highlighted in this article?

In part 2, I’ll explain my own journey with siloed development and go over some of the guidelines we’ve implemented to break down these silos and build collaborative teams that help eliminate the vast majority of the issues outlined in this post.


© Rian van der Merwe for Smashing Magazine, 2011.