Building a pattern library for fun and profit

One of the most beneficial activities you can do on a large design project (especially if it’s a web application) is to define a pattern library. This architectural document details the framework that all the UI screens and screen elements must use/follow. I like to explain what a pattern library is from the perspective of a journalist (it was my first college major) – I ask the standard questions who what when where why and how:

Who will use the pattern library? Developers? Other UI designers? QA? The details of the documentation supports the intended audience(s).

What does the UI element look like? How is it displayed and presented to the end-user?

When do you use one UI element rather than another? Provide examples of usage so that this can be clear.

Where in the UI are the elements presented? The pattern library should provide “templates” of the different types of screens so that positioning and placement are clear.

How do the UI elements behave? That should be specified explicitly and clearly. You notice I left out the “Why,” and that’s because the question is: Why have a pattern library in the first place. There are several reasons:

  • It provides a reference for future UI design work.
  • It documents UI behavior in one place instead of having to document it at the field level on al the design specifications.
  • It allows for one “source of truth” for all parties, thus reducing confusion.
  • It provides for a mechanism for enforcing consistency, which allows for structured design work.
  • It reduces design churn, it enforces consistency, and helps ensure quality.

The pattern library should have three primary pieces of content:

Templates: Details of the different screen types in the site or application

Containers: Collections of different UI elements (such as a results table)

Elements: Details on the discrete UI elements and rules around usage and implementation

A pattern library is traditionally NOT a style guide and so does not contain branding information – it to be used as a reference for UI designer. You can design a pattern library one of two ways – bottom up or top down. Bottom-up means you look at an existing UI structure or set of screens and you define the patterns based on them. This is the right approach if you are redesigning a legacy application, and you can do this at the same time you do a heuristic review of the application. Top-down means you look at defining page templates and standards from scratch (leveraging best practices and existing pattern libraries, of course).

Pattern libraries aren’t for everyone, as it takes a focused perspective to create an artifact that is useful and usable, and some projects are small enough that such effort is overkill. I was on one project where the person who created the pattern library took upon the work like it was the Great American Novel, and the results was a top-heavy document that was not the least bit user-friendly. For a good example of how to do a pattern library right, look here: http://www.welie.com/index.php

Good luck!

User scenarios, user stories, use cases – what’s the difference?

The three are different, but not as much as you may think. Let’s talk about stories.

No, not user stories… stories. We are wired to engage with and tell stories – it is a seminal part of the human species. It is the way we transferred knowledge before the written word, it is the reason why we have words – we need the words to tell the stories. Stories help us understand things, helps us learn and grow – stories nourish us as much as food and water does.

Stories are very effective things.

The three type of stories that are being discussed – user stories, scenarios, and use cases – all are different conceits that help communicate what a solution that is being created needed to do. The differences are in structure and perspective.

User stories are from the perspective of the end user, and very simple in structure:
As a (user type) I want to (action/feature) so that (reason)
As a (user type) I want to (action/feature) because (reason)

Example: As a runner I want to track the miles I run each day so that I can have a good understanding of how much I have exercised.

They also contain details that indicate what should happen, driven by context and other situations:
If (context) and (additional context) when (event) then (outcome)

Example: If I stop running and I stop for more than ten minutes, then the record of my run needs to be saved as a new run record.

User stories are used in the agile development process to scope features. They allow developers to focus on what the user has to do. The best user stories are grounded by user research and understanding – they aren’t “made up” and actually reflect what users have to do.

The next level of detail, the next “format” these stories can take in a design/development project are user scenarios. These are much more detailed and include details such as user’s motivation and environment. As opposed to the simple narrative of above, these are often presented in storyboards and as “blueprints” with a lot of details and texture that may often be superfluous.

User scenarios paint a picture that is more complete, but they are often viewed as superfluous on projects that have an aggressive schedule. When to use scenarios depends on the project and the needs of the project.

Finally, use cases are structured documents that contain requirements and details of what functionality should exist. Use cases are (usually) extremely entailed and detail both user behavior and system response. They are less about user needs and mental models and more prescriptive direction as to what needs to be developed. As these documents usually take some time to create, they have fallen out of favor with many companies who have adopted agile development processes.

So, the difference between the three type of stories? It’s all about approach, the author, and what detail is needed. For user experience practitioners, user stories and scenarios are the way most use to convey design direction and context. For business analysts, use cases is the known and used format. The line is getting blurred though – many business analysts are moving into UX these day. They key is to use the right tool for the right job, and to not overthink or over document.

After all, companies don’t ship design documents… they ship products and services produced from such documentation.

See question on Quora

Twenty great #UX quotes

Here’s some of my favorite quotes about user experience design – some are directly about UX, others are about creativity and simplicity. Enjoy.

“A picture is worth a thousand words. An interface is worth a thousand pictures.” Ben Shneiderman

“Good design is honest.” Dieter Rams

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” Antoine de Saint-Exupery

“If you can’t explain it simply, you don’t understand it well enough.” Albert Einstein

“If I had asked people what they wanted, they would have said said ‘faster horses.’ Henry Ford

“The architect should strive continually to simplify; the ensemble of the rooms should then be carefully considered that comfort and utility may go hand in hand with beauty.” Frank Lloyd Wright

“Do not accustom yourself to use big words for little matters. A man who uses a great many words to express his meaning is like a bad marksman who instead of aiming a single stone at an object takes up a handful and throws at it in hopes he may hit.” Samuel Johnson

“You can’t wait for inspiration, you have to go after it with a club.” Jack London

“A bad web site is like a grumpy salesperson.” Jakob Nielsen

“Simple is hard. Easy is harder. Invisible is hardest.” Jean-Louis Gassée

“Usability is not a quality that can be spread out to cover a poor design like a layer of peanut butter.” Clayton Lewis

“Confusion and clutter are the failure of design, not the attributes of information.” Edward Fufte

“Make everything as simple as possible, but not simpler.” Albert Einstein

“A lot of what we are doing is getting design out of the way.” Jonathan Ive

“As far as the customer is concerned, the interface is the product.” Jef Raskin

“Simplicity is not the goal. It is the by-product of a good idea and modest expectations.” Paul Rand

“When your work speaks for itself, don’t interrupt.” Henry J. Kaiser

“You are not the work.” Me

“To design an easy-to-use interface, pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behavior.” Jakob Nielsen

“Design is not just what it looks like and feels like. Design is how it works.” Steve Jobs

Get my book UX 101 as a free download!

After getting a lot of feedback (some good, some bad – all helpful) I have made some revisions to UX 101 and have finished up a second edition of the book. The new edition will soon be available on Amazon (in paperback and on the kindle) but, hey… Why wait? I have decided to make it available as a FREE download for any and all interested parties.

The key reason I wrote UX 101 was to provide guidance and education to newcomers interested in user experience, and the best way to get that information in thier hands is to give it away (though you can still buy a print copy if you’d like, of course).

You can download an optimized PDF of the book here, and I hope you like it!

The eight most common mistakes made on UX projects

I’ve worked in the UX discipline for over a decade now, and have been on a number of projects both large and small. One of the skills I’ve picked up in that time is pattern recognition, which helps me create personas and to identify trends to design for. It also helps me notice when things keep happening, mistakes that repeatedly occur over and over again on almost every design engagement.These mistakes can derail a project and, at the very least, make work more difficult than it needs to be.

I’ve identified the eight most common mistakes designers make on UX projects, and they are (in no particular order):

Undercommunication

Whenever a design team “goes dark” for too long the client starts to get antsy. Keeping key stakeholders in the dark will result in anxiety and frustration. So make sure you provide “check-ins” on a regular basis to let them know how things are going and preview designs whenever possible.

Overcommunication

Having daily stand-ups with the client may make sense for some projects, but not design. This often leads clients to think they can “micro-manage” design work at the pixel level, and that is not constructive. It leads to a frustrated team and stakeholders who end up focusing on the wrong things (details instead of “big picture” stuff).

How much communication is needed? Feel the client out, and do something that is obvious in hindsight: ASK. That will allow you to align your schedule and approach to their expectations.

Overdocumenting

UX designers need to document how a design works, so the developers can know what should be done to make the designs a reality. But design documentation are a means to an end, not an end in and of itself. The design team should document at the appropriate level to support development and testing – not write a novel. How much is enough? Again, communication is key – talk to the users of this documentation to understand their expectations. And, of course, find out what the client’s expectations are to make sure you hit that mark.

Underdocumenting

You can’t just sketch out the design on a back of a napkin and hand it to a developer or a stakeholder. You have to detail screen states, control behaviors, and map out the experience. Insufficient detail results in gaps in the experience and development and deployment issues

Following the same process for every client

You’ll notice that a lot of the mistakes I have cited so far involved design teams being inflexible – there’s a reason for that. No matter what IDEO or Frog will tell you, there is no ne “perfect” design process. You have to look at the context of the project the timelines, the expectations… and adjust as needed. Optimally you want to have some key activities that take place on every project, but you have to “time-box” some of the design sprints and work. It’s all about being “agile” and flexible about your approach.

Not doing enough (or any) research

One of the key activities refered to above is user research – you need to talk to end users (or potential end users) to understand their needs and inform the design. If you don’t have enough time, you need to make time – it’s that important. It gives you context and understanding to do good work, because you have someone you are designing FOR.

Not using analytics and legacy data

“I don’t need marketing research or analytics, I’m going to talk to users!” At the same time user research is important, you also need to leverage any details the client has to inform your understanding about the business “space” the design is intended for. Data can inform not only understanding put potentially trigger insights and ideas. But people who think they don’t need that type of information are often showing one of the worse mistakes a designer can make:

Arrogance

I’ve worked with several “know it all” design types whose ego are the size of a small planetoid. I think that arrogance blinds you to empathy and understanding, and this usually results in angry stakeholders and frustrated team members. UX design is vitally important but… it’s not curing cancer. Arrogant designers need to have some perspective.

 

There you have it, eight mistakes I don’t want any of my fellow designers to make. So go forth and design stuff!

 

What is the best way to create a UX roadmap?

First off, let’s discuss the term “UX Roadmap.” I’ve heard it used in a couple of different ways. Here’s one definition, from UX Game Changers:

The UX roadmap defines the stages of the user delivery. And while demands can change deliverables, the roadmap provides guidance and helps set priorities. The term “roadmap” is defined as being a course of action or a plan for future actions.  Roadmaps provide the underpinnings of what should eventually turn into efficiencies and revenue.

Here’s my take on it:

A UX roadmap details where your users are, where they want/desire to be, and when you will provide offerings that will take them where they want to go. It is a timeline of activities and offerings that is driven by user needs and aligned (and, optimally, influencing) product release schedules.

An example: You sell a widget that allows people to instantly see their blood sugar level. This widget does one thing – the blood sugar check – incredibly well. Your users like it because it is simple and effective. However, they want more – they want to be able to log this sugar over time, and they also want to not have to sync this information with their computers – they want to just have the information “beam” itself to there. And as these users get more exposed to similar technology, they will also want to have multi-function devices that supports more than one function.

They – and the world – are heading towards “multitasking enablers” that support  health monitoring. How do you evolve your product to keep up with that? You flesh out a roadmap based on research, understanding, technology, and society trends.

This is what a lot of product managers do, but their product roadmaps are often “keep up with the Jones” efforts, where they strive for feature parity with competitors. The secrets sauce is the UX roadmap, because it looks not at the competitive landscape but user needs and their mental models. If you don’t do that, don’t understand where people’s “heads” are at and where they are going… Well, it can lead to a failed product line and a dead company.

See question on Quora