Thinking outside of the <div>

An interesting article from UXBooth offers some great take-away points about approaching complex interactions:

  1. Realize that just because everyone does something a certain way it doesn’t mean you should do it, too. Popular design choices may not apply to your particular use-case.
  2. Layout the objectives of the design from the user’s point of view. Listen to customers to understand their pain points.
  3. Make a list of all the elements you want to include. Make sure each element has a clear function. Don’t just add things for the sake of it. Get pragmatic.
  4. Put everything together and see how it “fits.” Can you remove anything without jeopardizing the function of the element?
  5. Launch, test, iterate!

This process opened our eyes to the fact that a lot of designers might just be recycling standard design patterns resulting in sub-optimal experiences. I know we’ve been guilty of this. Are there places in your web-app where you might be doing the same thing?

Worthwhile advice when approaching any interaction, no matter how complex.

Ferrari Configurator!

As with their cars, Ferrari has created a really fantastic experience with their 458 configurator. Not only is the 458 gorgeous, but it’s a technological marvel with a seemingly endless number of options. The configurator will keep even the most critical desk jockey occupied for an entire lunch break. 

Overall, the configurator looks terrific, but it could use more contrast; viewing in my bright office made reading the text sometimes an eye-squinting affair. And while offering decent, and obvious, points of navigation—which is an important interaction that not all configurators do well—if I had to pick some nits, I would like the sections—both parent and child—to be more visually distinct from one another. As they are now, it’s not immediately obvious where a section begins and ends. Also, when clicked, a parent section expands horizontally to expose its children but in doing so the following parent section label is moved. Not a deal breaker, but not awesome.

As far as that red slider thingy at the bottom of the UI goes, besides being made taller, I’m not sold on the idea that it’s really necessary at all. I understand that it’s marking where the user is located within the work-flow, but since the user is able to navigate to any point in the flow at any time, an indicator of progress is not valid here.

Other than these small issues—that are easily ignored—the configurator is tons of fun, which after all is the real goal of these kinds of things. And for those of us who don’t quite (yet) have the scratch for the real thing, it’s nice that Ferrari throws us a bone with some cool online eye candy to kill some time until we do.

Related articles: Autopilot

Don’t just make it better

Every once in a while I need to remind myself that interaction design is not just about making a new thing better than an old thing. It’s ensuring that the thing—new or old—provides a great experience in comparison to nothing other than itself. It’s either good or it isn’t. Judging that something is working well for your users based on how it’s better than it used to be is no guarantee that your design is any good.

When looking for a new home, do you think that it’s reasonable to make your selection based on the current home’s condition as compared to its old condition? What if it’s a dump but the agent tells you that it also used to be a crack house? Would you buy it because a dump is better than a crack house? Of course not. So, if you, your colleagues, or clients claim that the existing experience is good because it’s better than it used to be, please stop. You’re doing yourself—and, most importantly, all your users—a disservice.

Instead rely on user testing and heuristic evaluations that will provide you the concrete data you need to ensure that what you have created is truly great and not just better than it used to be.

Oh, the irony

Several days ago, while checking email on her phone (natch), my wife received the above email from Microsoft. It seemed reasonable enough until she clicked the iPhone link within the “improved methods to get Hotmail on your smartphone” section. She received the following in response to her apparently misguided action:

Really? It’s hard to tell what Microsoft’s intention was here. Did they assume that since she wanted to read about using a smartphone to read her email that she would be using a PC to read the email? Considering that 27% of the word’s population (that’s 1.08 Billion for those who are counting) has a smartphone and is on it nearly constantly, it would seem that Microsoft would have made the connection between clicking on a link about smartphones and smartphone usage. They did not.

It should come as no surprise to anyone, especially Microsoft, that she was reading the email on her phone considering that they created a massive infographic that goes into ad naseum-detail about the subject of smartphone usage. According to them, not only is she the most active demographic but she spends twice as much time on her phone than she does eating. So, I have to wonder what they were thinking when they thought it was totally fine to tell her that she can’t use her phone to view information about using her phone. To Microsoft’s credit mobile phone usage won’t officially take over PC usage until 2014 so they can sit back a relax until then.

There’s a reason irony only works in books and movies.

Do this stuff and you’ll be almost as awesome as me

A great article written by Darren Garaghty for Smashing Magazine for UXers on what to do and why.

  • Know the language of your team members
  • Start with the simple questions: who, what, why?
  • Never lose sight of the problem you’re trying to solve
  • Know the user (it’s not you)
  • To tell the story you need to know the story
  • Be a skeptic (even when it’s not cool)
  • Data is your friend
  • Know your rationale
  • Fail? Big whoop.

Becoming a Librarian

It’s not that I was dreading writing an article about creating a UI standards library, it’s that I wasn’t sure where to start. It’s a big topic that spans years of effort on my part and the part of my colleagues. While I was beginning to outline some of the critical points I wanted to cover, I came across an article on Boxes and Arrows website that is an excerpt from Nathan Curtis’s 2009 book Module Web Design. In it he lists and defines the questions that an organization should ask before endeavoring to create a UX-related library. It is essentially a summarized version of the same one-question-at-a-time process that was used to help my organization build our existing standards library so I thought it made sense to follow his lead.

He starts by asking “Why Do You Want to Create a Library?” What seems like a very obvious question with what might seem like a very obvious answer it should actually be given a healthy dose of consideration. Creating a library is not a trivial undertaking, so ensuring that the goal of the library is clearly defined is imperative. The answer to this question will be the catalyst for creating the foundation of the library itself. But I do think that in most cases, even in small organizations, it’s a very good idea to have a library that provides in the very least a centralized location that every interested person can have visibility to.

So, the first question was a no-brainer. For our very large enterprise we were doing ourselves a disservice by not having an authoritative repository of UI standards. I think that it’s a great idea in and of itself but it was necessary in helping to address a fundamental goal in our IS department of providing our users a seamless experience. Without centrally published standards and well defined unilateral approach I don’t see how our organization—with dozens of independent applications spanning several business disciplines—would ever meet this goal. Because of this we  had already successfully answered the other questions Curtis poses regarding business stakeholder and design team buy-in. Our enterprise is enormous so in our minds there was no question that a library was necessary to the success of meeting our goals.

Once we had solidified our goal and determined that creating the library was a worthwhile endeavor we began the arduous task of building the information architecture, layout, and overall presentation the library would need to successfully communicate the vast amount information that would finally be published.

Curtis mentions at least two fundamental types of libraries, one for components and one for patterns. Although he seems to treat them as mutually exclusive entities, which is something that I don’t quite agree with, the overarching question gets at the heart of the most fundamental question: “are you building the right kind of library?” Indeed. And while this question is valid as is, for our needs I think that a more appropriate question is “are we building an effective library?” To me the distinction between pattern and components is insignificant. The guts are more important.

The Guts
To begin answering the question “are we building an effective library” we had to keep in mind our original goal: providing our enterprise a seamless user experience. We knew that eventually the library would include both components and patterns but I didn’t think that we needed to worry too much about the difference between them. What mattered was capturing the right level of detail. So, we asked ourselves, what is it that our teams need from this thing? As it turns out what they really wanted most were working examples. If we couldn’t provide a working example then a picture would do. The old adage of a picture is worth a thousand words was never truer. So, we focused on the solutions first.

Luckily we weren’t starting entirely from scratch. Over the preceding months I had been working with our designers to create a master feature list of components, patterns and other UI behaviors they thought were critical for creating enterprise-scale applications. If you don’t have a list already worked up, this is the most logical place to start. It may take time, but it’s the best way to articulate the need and value of each item which in turn will help you determine what to work on first. Eventually, we had a list of about 60 items. The items were mostly components as opposed to strictly patterns or behaviors, so it seemed reasonable—at least for the first version—that the library be tailored to describing the proper use and implementation of components.

Working with a small team I began creating the structure and content of the library. To get a good idea of category names I created and conducted a card sorting exercise sending it out to a group consisting of business analysts, business experts, developers, and other UI designers. The feedback that I received allowed me to create the initial categories.

  • Form Controls & User Input
  • Data Management & Display
  • Page Layout & Organization
  • Messaging & Feedback
  • Navigation
  • Visuals

We then set out to determine the level of information that would be appropriate for the same diverse audience that had taken the survey. In the very least we determined that we needed to include an overview and a working example (or sample image) of each standard.

The library needed to cover the following:

  • Name of the standard
  • Description of the standard
  • Problem the standard is meant to solve
  • List of appropriate and inappropriate use
  • Best practices
  • Example of what it looks like

If you’re a smarty-pants:

  • As many working examples of the standard that seem necessary
  • The ability for developers to see the mark-up that created the solution

If you are able to provide a working example and display the mark-up you will provide a huge service to your teams. This is the most looked at information in our library and it normally takes the least amount of time to create! In fact, if you are short on time starting with providing a working example with code and implementation details is enough. The other content (description, problem, when to use) is important but since our teams include a UI designer who was involved in the creation of the master feature list, the team can have the designer fill in the blanks until the remaining content gets created and published.

The Glory
Curtis asks two important questions regarding buy-in, “is your organization ready for a library?” and “is management ready to support a library?” These are about selling the idea that having a library is better for everyone than not having one. Working up your pitch, as Curtis mentions, is important. I don’t fancy myself much of a salesman but I am passionate about UX design. I normally tell the skeptics in my office that this is our way of meeting the goal of creating a seamless user experience. This usually shuts them up. Although we experienced some resistance from several business stakeholders who saw us as more of a hindrance than a help, the support that we received from upper management was critical to our success.

We were given the time required to create a fully realized, albeit first version of a UI standards library. This was the best sales tool we could ask for. You can talk all you want about how great a Porsche is, but no one wants to hear about a Porsche. They want to see it, feel it, and most of all drive it. This is no different with a UI library. It needs to bring immediate value and this is most easily achieved with something that works and can be taken for a spin. A Porsche with no engine is only interesting to a point. I’m harping on this point for a reason. In my experience, just having a library that talks about standards is not compelling enough to gain favor from your intended audience.

And just like the Porsche, not only should the library offer working examples and something immediately usable, but it should look good. The library itself ought to be a place that people will want to see because it looks and functions great as well as offers a great service. I used our existing application branding assets and relied on our front-end technology package to provide the right amount of look and feel. It’s important to maintain the same style or at least the spirit of the style that the library is proposing. In other words, practice what you preach and eat your own dog food. There are some aspects of the library that don’t fully conform to its own content but we maintain the general spirit of the standards.

Enough babbling for now. Let’s take a look at some examples.

Show and tell
Curtis has a terrific diagram that shows what goes into creating a design library. I suggest taking a look at this and reading the article that I reference in this post.

In the meantime, here are some images of the library that I helped create. I think they provide the best means of describing what I have spent so much time on these past few years. I would be remiss if I didn’t provide some examples!

left-hand navigation menu
Left-side navigation menu

left-hand navigation menu open
Each category expands to display each standard entry. A star indicates that the standard has changed or is new since the last version. A tool-tip gives more details about the specific changes.

example standard layout
Each standard shares the same set of sections broken up into a tab set. The last two tabs Performance Data and Audit Checklist support our own unique development process and are not required for a typical library. (click to view full page example)

An Enterprising Endeavor

Since 2008 I have spent most of time building a UI standards resource site. Essentially an encyclopedia, the site details the components, patterns, and standard interactions that our entire enterprise—comprised of dozens of applications across an array of business disciplines ranging from transportation to accounting—uses to create effective UIs. I work closely with designers, business owners, developers, and business analysts to establish the true need of our users. From the dim glimmer of fledgling requirements I propose, review, redo, review, negotiate, review, get the kids on the playground to play well together, review some more, and then eventually publish something that teams can use to best answer critical questions about user interaction. In reality this process can take a couple of weeks or as long as a couple of months depending on the complexity of the problem at hand.

In the end, what I do everyday, and have done for nearly a decade is solve puzzles. Some are easy; some are not. It’s the 3000 piece jigsaw of Guernica however that gets me up in the morning. The easy ones are great because you feel like your making huge progress immediately but when I’m able to help provide a solid solution for something that makes heads spin I feel that I’ve conquered the world.

This all takes time and energy of course, but I’ve learned to deal with that. Over the last few years I’ve come to realize my potential for patience. I work with eight other designers on a near constant basis facilitating the the creation of standards that work well across applications that for years have lived separate lives. It was only recently that our applications began to integrate. The goal is to create a “seamless experience.” On the surface this sounds like an awesome idea, but its meaning is nebulous. What does “seamless experience” really mean? And in what way is what I’m doing with standards development help in achieving this goal?

Lots as it turns out. Up until now I haven’t shared my thoughts about interaction design or the work that I’ve done over the last several years with the outside world. I talk ad nauseum all the time about it with my colleagues but never tried to publish outside of this bubble until now. As it turns out I’ve published a tremendous amount. The only way to see it however is to get a job at my company. Only the most intrepid among us will get a job where I work, so I’m going to detail the experience here so that it can be enjoyed from the safety of couches and coffee shops. In the meantime here’s a look at what I’ve been up to for the last 17 years (dang!), and a look at some of my work.