Sharing is caring

I’m in the midst of creating a mobile strategy for my current employer and thought I would share some of the more interesting resources that I found:

 

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.

Wireframes: the good, bad, and useless

As a UI designer, I’m constantly creating all sorts of documentation whether it be rough sketches on a whiteboard or a technical specification. In my article 1000 Words or Less, I touch on the applicability of wireframes in the design process:

Wireframes are purposely non-interactive. This is an advantage in the early stages of design. They not only keep the team focused but also decrease the time to get something in front of them.

While wireframes have their place, they aren’t as useful for documenting or maintaining the final design once coding has begun and should not be relied on to communicate the evolution of the design. Darrel Austin at uxformobile agrees and states in his article about the misuse of wireframes that:

They are an invaluable tool. What I am against is them being used as a document of record outside of the UX team. A wireframe simply can’t communicate the full complexities of the solution to every individual team.

I think this is accurate. He also goes further to suggest that an agile development methodology should serve to evolve the design into code faster and more efficiently than wireframes (and really most other forms of documentation) can. Wireframes as well as most other documentation inevitably become quickly outdated. The time spent making updates to the documentation can be spent sitting with a developer and updating the code.

The one place where I don’t quite agree with Darrel is that I don’t have a problem creating electronic versions of my wireframes. Where he would prefer to keep them on paper and whiteboards, I find that wireframes if used properly are as useful (more so in fact) if they can be shared via email, projected on a screen, or otherwise archived along with other project documentation that gets created along the way. Besides this, I agree with his final words of wisdom:

Focus on the product. Not the wireframes. After all, our users will never be using the wireframes.

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.

1000 Words or Less

As an interaction designer I’m sort of obligated to actually let people see my work. The document format I choose ultimately depends on what I’m showing, the audience, and how far along I am in the design process: start, middle, or end? Providing the right level of documentation at the right time is a powerful tool for creating the best design.

Start
For early-on-designs, I often choose to walk my teams through some wireframe mock-ups accompanied by a very basic narrative. I use Visio for these and found a nice template that mimics hand-drawn sketches (zip file). These are effective because as a tool for discussion the team can concentrate on how the business requirements are being met and less about how things look or behave. Wireframes are purposely non-interactive. This is an advantage in the early stages of design. They not only keep the team focused but also decrease the time to get something in front of them.

Middle
Eventually I have to make some actual real-looking UIs. More than just a nice picture for a developer to use as a model, polished designs serve other purposes as well: testing and validation.

As I’m moving through the design process, I ask myself when I want to test some of this stuff. Although I think I’m great, I’m not so great that I always get the design right the first time. I want feedback. Feedback from actual Users tells me if I’m on track or if it’s time to spend more time at the drawing board. My goal is to get the design to a point where not only does business agree that I’m meeting their needs (business validation) but that Users can actually get things done (User validation).

So, at this stage I’ll want to spend time creating UIs that look finished. For testing I’ll want to spend time making them feel finished too. With mouse-over, and on-click events I can make a UI feel as if it’s actually doing something—submitting data, navigating to another page, or removing an item. These are simple interactions that will produce good feedback. These I consider high-fidelity designs.

For business, these same mock-ups are put into a Design Walkthrough. Much like at the start of the design process, these high-fidelity designs are put into sequence with detailed descriptions and narratives that explain in more detail exactly how the UI is meeting both the business and User need.

End
Once a design is accepted I’ll provide either a UI Specification or a Design Brief. I’ll provide the developers and QA a UI specification that includes the finalized UIs including a description of each and details about what each piece of the UI does and how. For simpler designs, such as breadcrumb navigation (a UI standard) I’ll create something less technical.

Based on the same concept as a creative brief, the Design Brief is an overview of an interaction, component, or some other type of UI design widget. I’ve tailored this document for my own use and for the case of breadcrumb navigation, the goal is to publish the design in our UI standards library. Things that I ensure are included in a Design Brief are the problem being addressed, the design requirements, and the proposed solution. For our use, I include other sections as well, such as when and when not to use, target users, and a user story. These help to give context and rationale to the solution.

I like Design Briefs better than UI specs because of the sheer size of a spec and the time it takes to create and maintain. Design Briefs are put together quickly and are easier to update making them a perfect alternative to UI Specs and the perfect design document for working in an Agile development environment.


In the end, the kind of documentation you provide needs to make sense with where you are in the development process. It’s a delicate dance of sorts. I tend to use documentation to get only enough feedback to inform the next update to my designs. I have found that early on, keeping the team focused on how the interactions are meeting the business and user needs rather than how the color is distracting, or font is too small will keep meetings on point and give the right level of feedback needed to keep the design moving forward.

Move toward higher fidelity designs when you are prepared to put things in front of Users or you are comfortable with beginning to discuss how things are going to work technically. Because once business and developers see realistic looking UIs, the questions will be fast and furious and there will be no going back.

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.