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!

#UX101: Letting go and finishing

As important as iteration is when it comes to UX design, it’s also important to know when to stop. Too many times I have worked with designers who didn’t want to finish, who tweaked and changed and refined so much that (sometimes) the work had to be pulled away from them to be completed.

This is not the way to do it, for many reasons. First off, it makes you look indecisive and insecure… which does the whole UX discipline no favors, either. Second, it takes time away from the developers who have to execute your design, which is unfair to them.

Finally, any delay caused by excessive iteration endangers the project and could prevent ANY solution from reaching end users. The whole point of user experience design is to create solutions for people… to make their lives better. If nothing is ever “shipped”, then no one will get any benefit from what you have designed.

(This final point is especially important to me. I have worked on many projects in my time, and sometimes the project was halted before it was completed due to business decisions or budgetary reasons. Yes, the designs look good in my portfolio, but I’d rather the work benefit other people than just sit there unused.)

There’s a lot of reasons that some designers are like this… here’s some of them.

“Mr. Blue Sky”

Some of this excess iteration is driven by excessive optimism, where the designer is incredibly aspirational and wants to “change the world.” While I’m an incredibly optimistic person, I also have some perspective. The world is a very big place, and I’ve been involved in some design projects that did, indeed, make a big impact in the lives of a lot of people… but those are few and far between. We need to be realistic and temper our aspirations.

Designing for the next big thing

Lots of UX designers are, like me, fans of technology. Some of them are such fans that their designs aren’t feasible… yet. They design applications that would only work with “future tech” – advances that are being worked on in the lap, but are still months or years away from being released in the marketplace. This is not necessarily a bad thing, because we all need to dream big sometimes… but it’s not very practical if you are on a deadline-driven project. Doing this too often could also result in a reputation as having a “head in the clouds” and may impact opportunities and your career.

“Great artists ship”

This quote from Steve Jobs is one of my favorites, because it combines art and commerce in the most simple elegant way. User experience designers need to heed those worlds, and focus on results and outcomes rather than process. While I spent a lot of time in UX101 talking about process, I also tried to emphasize outcomes and deliverables as well. You have to finish, so that your visions and designs can become reality. Endless iteration means that you will never produce a final product, and that benefits no one.

“Perfect is the enemy of good”

This is another favorite quote of mine, an aphorism attributed to Voltaire. I have seen designers who iterate too much because they want everything to be perfect. Well, perfection will never be achieved, no matter how many times you tweak the details. Starting is hard… but for people with this attitude, finishing is even harder.

 

Conclusion

I’m sure if I spent more time writing I’d come up with lots more words to detail out the user experience domain… content that would (hopefully) explain more advanced techniques and information. But that would be #UX201, wouldn’t it? The point of this work is to provide foundational understanding and advice about UX to people who are new or interested in the domain. I think I’ve done that, and so I’m following my own advice: I’m letting go, and finishing.

(In fact, you can replace the words “user experience design” in the above section with “writing”, “painting”, “filmmaking” or any other creative endeavor, and most of the thoughts would still be appropriate and apt.)

This work was a labor of love – I don’t expect to get rich off of it, and in fact will be giving it away as much as selling it. The reason I did it, my “mission statement,” was to educate and inform, to hopefully get more people into the UX discipline… More practitioners mean more ideas, and more ideas means better ideas. Ideas that can raise the bar, making the quality level of the software and hardware we use better… resulting better experiences for all.

Will this happen? As noted above, I’m a practical man and I know my place in a (very big) world. Any impact will be minimal… but if this work helps even one person get into UX, or get better at their craft, then it will have been worth it.

If you have read this far, thanks! It’s up to you, now. Take these ideas, use them, and hone your skills. Design that cool UI or application that will make people’s lives better.

In the words of one of my favorite starship captains: Make it so.

#UX101: Bringing UX to your organization

You’re passionate about UX, you’ve “drank the Kool-aid” and you know how much value user experience design can bring to your company. Now what? How do you promote UX to decision makers and stakeholders? here’s some thoughts and advice as to how to work within your organization to get UX more attraction and interest.

Know your organization’s “UX Maturity”

Johnny Holland published a great “UX Maturity” chart, that measures the levels of understanding and application of UX in an organization. It goes from Level 1 (“Unrecognized”) to Level 6 (”Embedded”). Knowing where your company is in this continuum will help you know the level of discourse and education you need to have, so you can speak to the value of UX at the proper level to the right people.

Nothing succeeds like success

The easiest way to get attention to UX is to be successful applying UX to a project. After you succeed, you then have a story to tell people and this case study can help increase interest in applying more UX principles. If you are not in a position to apply UX to a paying project, do it on an internal effort – solve some process problems or improve deliverables. Even if you can’t make a big impact, the key is to build your case and have a story to tell – as noted earlier, we are hard-wired to respond to stories and this makes things easier.

Don’t try and do it all 

Take baby steps, and use only one or two UX techniques to solve problems. This way you can be more focused and won’t be “swinging for the fences” on your first at bat. Build your skills, and successes,one step at a time.

Understand how things are being done now

Spend some time learning current processes to get a good sense of potential “insertion points” where UX can add value or save time. This will show management you know what you are talking about, and therefore increase your credibility when you propose changes.

Get an executive “cheerleader”

If you have the buy-in of an executive, that is worth its weight in gold. Executive support can get you funding, break down barriers, and help you in many many ways. I have seen just how important such support is first-hand… when I had it, and when I didn’t. Reach out to an executive to make your case and get that support if you can.

Apply UX in the early stages of a project

If you are working on projects, bring UX practices into the early part of projects instead of later. When you are in a project’s early days, the tolerance for failure is higher and deadlines are (usually) not as aggressive… so if the UX practice you apply doesn’t work, there is less chance the application of same will blow up in your face and give UX a bad reputation to management.

Don’t be discouraged 

Organizations large and small are established in their ways, and many organizations are reluctant to change. When you try and “rock the boat” and do things differently, you will see first-hand that hesitancy. Sometimes you will think you are banging your head against a brick wall… don’t let it get to you. Keep trying to make UX a priority at your company, and be positive as much as you can.