Boxes and Arrows

Leaping Into Indie UX

Jeff Parks — Tue, 22 May 2012 14:42:05 GMT

Show Time: 33 minutes 40 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

Podcast Summary

In this episode Chris Baum speaks with Donna Spencer, Lynne Polischuik , Justin Davis and Erin Jo Richey at the 2012 IA Summit about their interactive panel discussion Taking the Plunge: Diving Into Indie UX. They share practical and personal considerations of being an indie designer, including how to to get over the fear of making the jump, where and how to find clients, managing the business side of design and what it’s like to work alone.

Quotes

“When you first start this you are really insulated…when I looked back it in the first six months to a year I didn’t make any money! When you’re in that initial phase you’re really excited… I think if you looked at it objectively you’d never do it.”

“I spent three years working my butt off to have all of the buffers in place… if there’s no work there’s no backup second income. It took a good couple of years to get enough money in the bank… where I could finally start to relax and say no to work knowing other things would come up and not kill me.”

“I got pushed out of the nest with a reasonable size contract.. and I was OK for a couple of years but I look back now on projects I took on that now I never would have taken on… taking on the wrong clients, taking on the wrong projects… I got to a point recently last Fall where I asked am I happy is this where I want to be?”

“I have been an independent for just over a year now… I had joined the agency that would come in as an analyst and then transition to an Information Architect. We decided that they didn’t want to take the agency in the direction of UX or IA and we talked about the role within the company… I didn’t want to focus on the same types of marketing … I did get laid off but I didn’t have a backup plan put in place.”

Thanks!

Thanks to “Vitamin Talent”:http://vitamintalent.com/ and Morgan Kaufmann’s “It’s Our Research”:http://www.amazon.com/Its-Our-Research-Stakeholder-Buy-/dp/0123851300/ref=sr_1_1?s=books&ie=UTF8&qid=1331302670&sr=1-1 for sponsoring this podcast.

And thanks to “ASIS&T”:http://www.asis.org/ for their support of the “IA Summit”:http://iasummit.org/ and this podcast.

Driving Holism in Cross-channel Projects

Chris Baum — Thu, 19 Apr 2012 05:39:51 GMT

Show Time: 29 minutes 29 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

iTunes

Podcast Summary

Today on Boxes and Arrows, Chris Baum talks with Patrick Quattlebaum, Design Director at Adaptive Path. Patrick has some interesting insights and tools that designers can use to develop experiences across channels. Quattlebaum explores the difference between atomism and holism, and how designers often struggle with making parts of an experience that really needs to be thought of as a whole. He also discusses how he navigates relationships in large organizations across teams building different parts of the experience. Finally, he talks about how he brings those teams together using the “rough cut” from film to show the whole context of the experience and find “bridges” between channels that might be missed if the parts are developed separately.

Quotes

“[As designers,] we did research and strategy, and draw great concept diagrams, and try to sell a vision. Many times it didn’t play out, or would play out, but was missing those crucial elements that really made it what it was. It’s never going to be the way you thought it would be on paper.

More lately, I’ve been thinking about atomism, about how companies break things down, and work separately and how that makes thing harder. It’s not something we need to say, ‘Well, that’s just how companies are,’ and just give up or do the best we can with what we can control with digital or the touchpoint that we own and not worry about the other things.”

“I personally can’t stop worrying about the other things and the big picture what i wanted to do is encourage people to communicate that with everybody that they work with. That’s what everyone is trying to do. It’s easy to get lost in your area of responsibility and what you can control, but that’s not going to get us where we know that customer experience and user experience needs to go.”

“What designers and IAs do is find those connections across the work stream that is going to be the experience in the design. They make sure there’s the right balance or consistency among all the diff’t touch points, without being a slave to total consistency.”

Notes

Follow Patrick on Twitter ”@ptquattlebaum”:https://twitter.com/ptquattlebaum
Find “his presentation”:http://t.co/gHFKTN8a from the IA Summit on Slideshare

The Past and Future of Boxes and Arrows

Jeff Parks — Mon, 09 Apr 2012 23:29:36 GMT

Show Time: 21 minutes 06 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

iTunes

Podcast Summary

In this episode, I had the pleasure of sitting down in New Orleans at the 2012 Information Architecture Summit with Christina Wodtke (@cwodtke), the founder of Boxes and Arrows.com. Christina shares a bit of the history and future of the web magazine that has supported both the people and ideas that have played a key role in the continuing growth and evolution of the IA discipline.

Her key message is that designers need to get their ideas out there.

“You know what really terrifies me? That so few people actually write about what they are doing. There’s so much intelligence lying around out there and not getting out. I just want to find a way to get these folks in front of the people that need to hear them.”

Pitch in on B&A

In that spirit, Boxes and Arrows seeks editors and writers. “Participate!”:http://boxesandarrows.com/about/participate.

Also, the community will come together at the Boxes and Arrows Fall 2012 Retreat. Interested? “Retreat!”http://boxesandarrows.com/about/retreat

Thanks!

And thanks to “ASIS&T”:http://www.asis.org/ for their support of the “IA Summit”:http://iasummit.org/ and this podcast.

Das Design Revolution

Stuart Neale — Tue, 20 Mar 2012 05:32:42 GMT

Experience design comrades, I speak to you today because I have a vision. A vision where one day the person who really matters is back at the heart of our design processes. Rightfully claiming pride of place at the centre of all decisions regarding our websites, interfaces and systems. I am talking, of course, of the Designer, or more specifically, the Designer’s Portfolio.

For too long have we pandered to the user-centered orthodoxy at the expense of beautiful 1,200px wide images crafted for CSS gallery websites. How can we be expected to turn a small corner into a 400×300px snapshot that looks good on Dribble.com whilst having to worry about user personas? How can we expect Patterntap.com to accept our gorgeous, beveled navigation system if we have to spend time considering things like reassurance, orientation or SEO?

We are forced by project teams to worry incessantly about requirements: the user’s, the business’s or even, heaven forbid, the client’s. Our KPIs continually push us to sacrifice our design flourishes at the alter of ‘simplicity’ or even ‘usability’, whilst paying no heed to fulfilling our fundamental needs as frustrated Fine Artists or Filmmakers.

So in response to this I propose a new way of thinking about our practice. A revolution if you will. Set your iPhone lamp to ‘on’ and let it illuminate the darkness of agile prototyping methodology toward a shining new revelation:

h3. Portfolio-Centered Design

“I’m with you!” you tweet, “but how can we blindly follow you with no manifesto?”. Fear not; using my own process I have carefully crafted a ten-point system (because ‘ten-point’ always sounds best, regardless of how many cogent points I can actually come up with) for a designer to keep in mind. Consider these a checklist that will help you achieve the pinnacle of a shining portfolio, and get that all important job in an interactive marketing agency, turning above-the-line advertising into social media campaigns.

1. First and foremost, context is nothing

For a designer to have to think about a portfolio that is anything more than a series of images accessed by menus of thumbnails is absurd and not worthy of consideration. After all, if it’s good enough for art galleries then why not for us? We have to remember that our designs are essentially a series of pictures: to be looked at, commented on and copied in a suitably reverential setting.

Only this way can they truly ‘breathe’ as we want them to. Only then can we see their true aura, stripped of superfluous information, context or brief. Only then can they be evaluated without reference to requirements or KPIs, changing digital landscapes or touchscreen shapes and sizes.

2. Don’t pay too much attention to testing

How can users meaningfully assess your designs? They might have no prior knowledge of the system. Surely the best-placed person to decide if a series of pages works is the person who designed them. It’s obvious that only they really know what each item means and are best placed to understand the design decisions behind it.

Too often do I hear designers overruled with questions about users’ comprehension. Too often have I heard arguments citing Cognitive Psychology. Too often have principles of human behaviour and capabilities trumped good, solid layout decisions.

If the designer has seen the problem solved by their favourite app on their iPhone, which was approved by Apple, then it must be the best process and the users will eventually just learn how to use the system.

3. You can never arrive at a solution too quickly

If you can re-write a brief with as many solutions upfront as possible, this will significantly cut down on research, iterations, and those frustrating workshops with the wider team, clients or users. You are not a business consultant and this approach will free you up for the important jobs, like deciding which Smashing Magazine social icon set best reflects current design trends.

This also allows you to fill the gaps in your portfolio. Missing an AJAX carousel? Seen a good example of one? Simply set up the brief so the project needs a carousel (there has to be an explanation for them existing).

Finally, that portfolio needs a current, on-trend solution? Simply find yourself one (preferably popularised by industry gurus) and retro-fit the project requirements later. You can have these two for nothing: embedded fonts or responsive design (will work for about another six months or so).

4. Content is not your job

We cannot be expected to be storytellers; it is not our job to guide people through our sites. This is the job of the content strategist or copywriter and can be done right at the end. Taxonomy, nomenclature and so on, these are simply not as important as getting the colour pallet nailed.

There is a great tradition of using dummy Latin text in advertising. So why not stick to it? It makes us look like our fledgling field has roots in an older and more accepted field like advertising layout.

5. Considerations of technology – somebody else’s job

Do not collaborate with programmers. Keep as far away as possible, do not let them stifle creativity. Only the ‘Creative’ team is really qualified to come up with UX solutions; they’re the ones who went to Art College after all. Maintain a good ‘over-the-fence’ relationship with the technical or engineering team, and none of their prototyping or agile methodology will get in the way of your blue-sky design thinking. This leads us neatly to –

6. Collaboration, not exactly a dirty word, but a bit icky

Again, advertising can be our paradigm here. Silos keep things simple. Strategy is best left to the strategy team, user research and engagement to the IA team, and so on. Demand polished wireframes (think ‘scamps’) to colour in.

Client management? You know where the account team is. Keep your engagement to carefully planned walkthroughs, making sure the number of solutions to be presented is pre-arranged so there are no surprises. If in doubt, just remember headphones can be a designer’s best friend.

7. Accessibility works best as an afterthought

This is what the principle of ‘degrade gracefully’ was invented for. Always design for the highest spec users. This allows you total creative freedom, unencumbered by limitations of contrast, plug-ins, browsers, user’s disabilities and so forth. It is self-evident that only this can produce the most creative design solutions.

Then simply allow the site to ‘degrade gracefully’ and everyone who doesn’t sign up to your setup can simply enjoy an experience more suited to their system, or their personal limitations.

8. Photoshop: let that be where responsibility ends

If you can fill your folio with the initial designs, it ultimately doesn’t matter to you how it turned out in the browser, or whether KPIs were achieved. Sticking to your goal of beautiful pictures above all else allows you to keep your involvement ring-fenced to the early phase of the project and avoid the difficult responsibilities later on.

This keeps you free to make sure you always have your ear to the ground for the next portfolio-worthy project to work-up in Photoshop and get onto your site.

9. Lorem ipsum dolor sit amet

Don’t be afraid of filler content to fit a nice pre-existing pattern. As I said ‘ten-point plan’ sounds better than ‘nine-point plan’. Whether the site experience works as a flow over multiple pages is not evident from portfolio grabs, so don’t worry, you are safe.

10. Don’t throw your net too wide

You’re crafting visual designs, so restrict your influences to that field. You can’t be expected to have time to absorb other mediums, have other interests or think about how they could relate to the problems we are trying to solve.

Your influences should come from within digital and possibly graphic design. What can film or games design teach you? Architecture is about buildings not websites. They are fundamentally different disciplines and will only confuse the design purity. Remember: “if it’s not Swiss, give it a miss.”

Keep all these in mind, and that award-winning portfolio could be yours!

Just don’t send it to me, that’s all I ask.

The Story's the Thing

Andrew Hinton — Thu, 08 Mar 2012 19:06:25 GMT

_This is an excerpt from “UX Storytellers”:http://uxstorytellers.blogspot.com. If you enjoy it, consider getting the kindle edition of UX Storytellers – Connecting the Dots with all the stories!_

Here’s something I believe in: stories are what make us human. Opposable thumbs? Other animals have those. Ability to use tools? Ditto. Even language is not exclusive to human beings.

From my amateur reading of science, the story behind our stories goes something like this: the human brain evolved with an uncanny knack to recognize and create patterns; and through some strange twist of natural selection, gradually over millions of years, our brains started turning the incredible power of that pattern-making machinery on ourselves, until we became self-aware.

Aware of ourselves—our own faces, bodies, journeys, homes, children, tools, and everything else around us. Over eons, we went from being creatures that lived in each moment as it came and went, to protagonists in our own myths. Everything in our midst became the material for making stories, strands of moments woven into tapestries that we call things like “nation”, “family,” “love” or “discovery.”

And “design.” Because design is, ultimately, a story we make. And designing is an act of weaving a new story into an existing fabric in such a way that it makes it stronger, better, or at least more interesting, and hopefully more delightful.

h3. An Origin Story

My identity as an information architect happened accidentally, and gradually. I just kept doing things I liked, that people were willing to pay me for, until I woke up one day and realized I had a career. And the things I liked doing were invariably surrounded by people’s stories.

One of the earliest jobs I had out of college (after trying my hand at carpet cleaning, waiting tables and telemarketing) was as an office manager in a medical office. It was 1990, and this office of five or six providers was running entirely on a phone, a copier and an electric typewriter. No computer in sight. Every bill, insurance claim, or patient report had to be typed anew … as if the 80s had never happened. I talked the owner into getting a computer and a database management package—a sort of Erector set for database application design that I’d seen at a Mac user group a year before—so I could make the office more efficient.

It would’ve been pretty easy to create a quick application with a minimal user interface, if I were the only one using it. But the owner also had a couple of people helping in the office part-time who needed to use the system too—people who had never even used a computer before. Did I mention this was 1990?

So I had a challenge: how to make it work so that total computer newbies could use it? It was frustrating, fascinating, and probably the single most important experience of my career, because it was a crucible for acknowledging the importance of understanding the user.

To understand the people who were to use the application, I had to talk to them, get a sense of what they’d done before and what sort of forms they had used in the past. What sorts of technology? What terminology was going to make sense for them? How do they tend to learn—by written instruction or hands-on activity, by rote or through improvisation? I learned these things by watching and conversing. Eventually I had enough of a sense of those “users” that I had a full story in my head about how they came to the experience of this particular application, in this particular place.

I wasn’t conscious of this at the time; and I was working completely by intuition. I would’ve done a better job if I’d had the experience, methods and tools I’ve picked up since. But looking back, the experience itself has become a story I tell myself when I need a rudder to remind me of my direction as a designer so that, even when I have nothing else to go on, if I just watch, listen and absorb the stories of the people for whom I’m designing, my design will generally head in the right direction.

h3. An Architecture Story

Much later, about ten years ago, I was working at a web design agency, and our client was an organization that acted as a sort of confederation of research scientists, universities and technology corporations. The organization funneled research money from “investor” companies to the scientists and their students in the universities, and in return the companies received “pre-competitive” research and dibs on some of the brightest graduates.

Their website had evolved like so many in those days—having started from a few linked documents, it had grown by the addition of ad-hoc sections and content created in response to member requests and complaints, until it had become a horribly unwieldy mass of links and text. We had been called in to clean it up and organize it. That sounded straightforward enough. But when we started interviewing its users, we found people who were unhappy with the organization and its community in general—scientists who had become more entrenched in their own sub-disciplines, and divisions between those managing the community and those merely dwelling there. Not to mention the natural enmity between academics and business leaders.

We realized that the web site had become a visible instantiation of that discord: a messy tangle of priorities in tension. A new information architecture would mean more than just making things more “findable.” It meant trying to make a digital place that structurally encouraged mutual understanding. In essence, a more hospitable online home for people with different backgrounds, priorities and personalities. It was a chance to create a system of linked contexts—an information architecture—that could help to heal a professional community, and in turn strengthen the organization founded to support it.

That project provided an insight that has forever shaped how I understand the practice of information architecture: the web isn’t just a collection of linked content, it’s a habitat. And the structures of habitable digital places have to be informed by the stories of their inhabitants.

h3. A Survival Story

Much more recently, I had the opportunity to work with a non-profit organization whose mission was to educate people about breast cancer, as well as provide an online forum for them to share and learn from one another. When interviewing the site’s users, it soon became clear how important these people’s stories were to them. They would tell the tale of their cancer, or the cancer of a loved one, and in each case the story was one of interrupted expectation—a major change of direction in what they assumed to be the storyline of their lives.
I learned that this website was merely one thread in a great swath of fabric that the site would never, ultimately, touch. But the site was most valuable to these people when it supported the other threads, buttressed them, added texture where it was needed, especially when it helped fill in the gaps of their stories: How did I get cancer? What do my test results mean? What treatment should I choose? What can I eat when getting chemo? How do I tell my children?

They wanted information, certainly. Articles full of facts and helpful explanations. And the site did that very well by translating medical research and jargon into information people could use. But even more than the packaged articles of information, so many people wanted—needed—to share their stories with others, and find other stories that mirrored their own. The most valuable learning these people discovered tended to be what they found in the forum conversations, because it wasn’t merely clinical, sterile fact, but knowledge emerging organically from the personal stories, rich in context, written by other people like them.

One woman in particular lived on an island in the Caribbean, and had to fly to the mainland for treatment. There were no support groups around her home, and few friends or family. But she found a community on this website; one that would cheer her on when she was going to be away for tests, console her or help her research alternatives if the news was bad, and celebrate when news was good. She made a couple of very close friends through the site, and carried on relationships with them even after her cancer had been beaten into submission.

Here were stories that had taken hard detours, but had found each other in the wilderness and had become intertwined, strengthening one another on the new, unexpected journey.

This work, more than any other I’d done before, taught me that stories aren’t merely an extra layer we add to binary logic and raw data. In fact, it’s reversed—the stories are the foundations of our lives, and the data, the information, is the artificial abstraction. Information is just the dusty mirror we use to reflect upon ourselves, merely a tool for self-awareness.

It was through listening to the whole stories as they were told by these digital inhabitants that I learned about their needs, behaviors and goals. A survey might have given me hard data I could’ve turned into pie charts and histograms, but it would’ve been out of context, no matter how authoritative in a board room.

And it was in hearing their stories that I recognized, no matter how great my work or the work of our design team might be, we would only be bit players in these people’s lives. Each of them happens to be the protagonist in their own drama, with its own soundtrack, scenery, rising and falling action, rhyme and rhythm. What we made had to fit the contours of their lives, their emotional states, and their conversations with doctors and loved ones.

h3. The Moral of the Story

Design has to be humble and respectful to the presence of the user’s story, because it’s the only one that person has. Stories can’t be broken down into logical parts and reconstituted without losing precious context and background. Even though breaking the story down into parts is often necessary for technological design, the story lives only if we serve as witness to the whole person, with a memory of his or her story as it came from that person’s mouth, in that person’s actions.

Keeping the story alive keeps the whole idea of the person alive. Whether we use “personas” or “scenarios” or task analysis or systems thinking, the ultimate aim should be to listen to, understand and remember the stories, precisely because the stories are the beating heart of why we’re designing anything at all.

So, now, when I’m working on more mundane projects that don’t touch people in quite the same way as some of the others I’ve done, I still try to remember that even for the most everyday task, something I design still has to take into account the experience of the whole person using the product of my work. That, after all, is what we should mean when we say “user experience”—that we seek first to listen to, observe and understand the experience of the people for whom we design. We honor them in what we make, when we honor their stories.

Leonardo's Kitchen Nightmare

Brian Sullivan — Wed, 15 Feb 2012 08:11:31 GMT

“It’s easier to resist at the beginning than at the end.”
Leonardo Da Vinci

Some of Leonardo’s projects failed because of their execution. The strange tale of Leonardo’s “Kitchen Nightmare” plays out like a Shakespearean “comedy of errors” where a visionary designer’s experiments all work perfectly to extremely disastrous results.

In an article for the Big Design blog, I wrote about the Five Sketching Secrets of Leonardo Da Vinci, where it seemed like everything Leonardo did was successful. This, however, is not the case.

Once upon a time, the Duke of Milan asked Leonardo Da Vinci to help his kitchen staff prepare an extravagant meal for a large dinner party ^[1]. Leonardo was well known for his dietary practices (he was a strict vegetarian) and his many inventions (parachutes, tanks, gliders). So, Leonardo set about to see how he could innovate in the kitchen.

Seeing several opportunities before him, Leonardo created several new innovations:

Developed a series of conveyor belts in the kitchen to bring food to cooks faster
Created a large oven to cook food at higher temperatures than normal (at the time)
Designed a sprinkler system for safety, in case a fire broke out
Invited local artists to carve individual entrees into works of art for guests to eat

As you can guess, it was Leonardo’s “kitchen nightmare.”

When Works As Designed Still Fails

Imagine this scene in your own kitchen.

A designer comes over to “help” you cook dinner. He creates a conveyor belt in an already crowded kitchen. You have never seen or used the new oven that cooks faster than what you have been using for years. The designer installs a sprinkler system, which further crowds the kitchen. Finally, the designer invites 50 or so artists to build edible art for the guests. Your kitchen is super crowded. You feel impending doom at the chaos that has invaded your kitchen.

Disaster strikes!

The comedy of errors begins with the conveyor belts running too slow. With a quick adjustment by Leonardo, the belts run faster. Soon, the food piles up. The belt needs another adjustment.

Next, the new oven works as designed, but the cooks burn the food, using this unfamiliar oven. Besides burning the food, the new oven causes a small fire. Naturally, the sprinkler system is used. The sprinklers works perfectly, but it ruins most of the food.

Finally, the artisans carving the food are too slow. The guests, who were promised an extravagant dinner, are starving. Most of the guests go away hungry.

The Duke, of course, was embarrassed and angry. Leonardo was publicly humiliated.

Three Lessons for Designers

Leonardo’s “Kitchen Nightmare” offers several lessons for designers. I will talk about three lessons here:

Do not be afraid to fail
Use positive judgment to explore the value and benefit of ideas
Do not underestimate the importance of executing your ideas

1. Do not be afraid to fail

First, do not be afraid to fail. Da Vinci was using conveyor belts long before the Industrial Revolution. He was experimenting with higher temperature for cooking, developing his own oven, and using artists to improve the presentation of food. Leonardo developed a sprinkler system, which contains the fundamental design still used today.

When faced with a task of preparing an extravagant meal for the Duke of Milan, Leonardo was inspired to improve the current state of technology in the kitchens of the day. He was not afraid to fail. Leonardo was no “Iron Chef.” And, he failed in a spectacular way. Again, do not be afraid to fail. Leonardo was not.

The fear of failure is a great barrier to creative thinking. You learn from your failures. Leonardo puts it best:

“I have been impressed with the urgency of doing. Knowing is not enough; we must apply. Being willing is not enough; we must do.”
Leonardo Da Vinci

Fear of failure stifles your thinking. Fear of failure keeps you thinking inside the box. You can learn from failures. You can think creatively.

2. Use positive judgement to explore the value and benefit of ideas

Second, use positive judgment to explore the value and benefit of ideas. Consider yourself as the Duke of Milan, who was just publicly humiliated by Leonardo’s “innovations”.

Would you take the time to notice the value and benefit of conveyor belts, new ovens, and sprinkler systems?
Would you think about the creative concept of using edible art designed by local artisans for your guests?

The answers to both questions is, most likely, no.

When faced with new ideas or failure, we are quick to judge things negatively. We fail to explore lessons learned. We fail to see the benefits and values within new concepts. We do know the Duke publicly humiliated Leonardo for his “kitchen nightmare.” Ironically, the Duke’s own army could have used the same technology (conveyor belts, ovens, and sprinklers) to build more weapons faster. Instead, the Duke scoffed at these new innovations because he was embarrassed.

When you are faced with a new idea in the future, use positive judgment first by asking your “self” a few basic questions.

What are the benefits and values of this new idea?
In what ways can this new idea work?

As designers and UX professionals, you want stakeholders to consider the value, benefits, and novelty of ideas before quickly dismissing them. Using positive judgment first when a new idea is introduced leads you to explore potential ideas and consider alternatives. You do not quickly jump to the most common design solution, newest technology, or known design pattern.

“The greatest deception men suffer is from their own opinions” is a famous quote from Leonardo Da Vinci. In this lesson, Leonardo want us to consider the novelty of new ideas rather than our initial, negative reaction, where we judge all the reasons an idea will fail. When you use positive judgment first, you balance your tendency to quickly react to new ideas. 

3. Do not underestimate the importance of execution

Third, do not underestimate the importance of executing your ideas. Leonardo made significant inventions for one dinner party. The inventions did work as designed. The conveyor belts moved the food. The oven cooked at a higher temperature. The sprinklers put out the fire. The cooks (ie users) were not ready to have three different inventions at the same time. When you add 50 or so artisans, the kitchen gets very crowded, very fast.

Execution is critical.

Leonardo’s Kitchen Nightmare was brought upon by Da Vinci not following his own advice:

“Experience does not err. Only your judgments err by expecting from her what is not in her power.”
Leonardo Da Vinci

First, consider how the story of Leonardo’s Kitchen Nightmare might be affected by just following modern UX best practices. Leonardo could have started with the 5Hs and W to get better understanding of his design problem. He could have developed personas for the cooks, artisans, servers, the host, and the dinner party attendees. Leonardo could have done some usability testing with the cooks and artisans, where he could have tested out his assumptions with real users.

Second, consider how Leonardo’s execution was seemingly affected by some poor project management practices. Leonardo introduced three new inventions (conveyor belts, sprinking system, and new ovens), as well as new people (the artisans) doing additional activities (carving food). Leonardo was a poor project manager. He added new features and tweaked existing ones, which only added to scope creep. Clearly, Leonardo had planned on doing too much with his project.

Finally, consider how the execution of these kitchen ideas were affected by Leonardo himself. Leonardo was famous for procrastination. For example, it took him many years to complete “The Last Supper”. When you look at the body of his art work, you will discover only a small set of completed masterpieces. From an execution perspective, we see only one resource (Leonardo) for all these ideas. Leonardo was overthinking and underdelivering on his promises, which is a nightmare on any project.

Conclusions

Leonardo Da Vinci did not always succeed. When he failed, it was a spectacular failure. It was a living nightmare. Leonardo may have said it best:

“It has long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things.”
Leonardo Da Vinci

His failures still show us lessons from Leonardo.

Do not be afraid to fail, as you learn the most from your attempts. Judge new ideas with a positive viewpoint to explore the value and benefit of potential ideas. The execution of a new idea can be as important as thinking it up.

You can design like Da Vinci.

Footnotes

1 Gelb, Michael. How to Think Like Leonardo da Vinci: Seven Steps to Genius Every Day. Dell, 2001.

Integrating UX into the Product Backlog

Jon Innes — Fri, 03 Feb 2012 08:48:50 GMT

Teams moving to agile often struggle to integrate agile with best practices in user-centered design (UCD) and user experience (UX) in general. Fortunately, using a UX Integration Matrix helps integrate UX and agile by including UX information and requirements right in the product backlog.

While both agile and UX methods share some best practices—like iteration and defining requirements based on stories about users—agile and UX methods evolved for different purposes, supporting different values. Agile methods were developed without consideration for UX best practices. Early agile pioneers were working on in-house IT projects (custom software) or enterprise software ^{[1, 2]}.

The economics are different in selling consumer products than when developing software for enterprises—UX matters more for consumer products. Jeff Bezos cares if users know how to click the button that puts money in his pocket more than Larry Ellison cares about any button in Oracle software. Larry makes money even if people can’t use his software. Oracle sells support contracts and professional services to fix things customers don’t like. Amazon and other online businesses can’t operate like that. They have to get the UX right, or they go out of business fast. User experience factors rarely get the same level of consideration when the end-user is not the same person as the paying customer ^[3].

Agile teams and UX problems

I’ve encountered two problems common among agile teams when helping them improve the user experience of their products or services:

UX work is frequently overlooked during the release and sprint planning efforts.
Teams often fail to measure the UX impact of their iterative efforts.

These two problems become more serious when combined.

When UX work goes undone and the impact is not measured, the team doing the work has no idea what is going on. The feedback loop is broken. Both agile and UX methods emphasize iteration, but productive iteration requires good feedback loops.

You can conduct development iterations (the focus of agile) or design iterations (the focus of UX), but if you fail to measure the impact of the iteration, you won’t see the real benefits of an iterative process. You will have no real idea if your offering is any closer to meeting the needs of the end user. The User Experience Integration Matrix (UXI Matrix) addresses these problems by tying UX to the project backlog.

Integrating UX into the product backlog

“ You can conduct development iterations (the focus of agile) or design iterations (the focus of UX), but if you fail to measure the impact of the iteration, you won’t see the real benefits of an iterative process. You will have no real idea if your offering is any closer to meeting the needs of the end user. ”

Scrum (one of the most popular variants of agile) advocates you create a Product Backlog, a collection of stories that describe user needs. The team iteratively refines the requirements, from rough (and often ill defined) to more specific. This is achieved using stories from a user’s perspective, which have conditions of satisfaction associated with them. This concept is adapted from UCD’s scenario based design methods. In my view, this is far better than other traditional approaches to documenting requirements that are often detached from user’s goals.

Various agile gurus ^{[4, 5]} discuss how to break down requirements from high-level stories to user needs targeted at specific users. Even if your team follows Jeff Patton’s story mapping method ^[6], (which I highly recommend) to create structured hierarchical representations, you’ll often find you want to analyze the stories by different factors as you groom your backlog.

I’ve worked with teams who want to analyze stories the following ways:

Order of dependency or workflow (self-service password reset depends on user registration)
Criticality (which of these stories must be done so customers pay us next month)
How much work will they take to complete (show me all the epics)
What related stories do I have (find requirements with related UI patterns)
By role or persona (show me all the stories that impact persona X)
What stories have a high impact on the UX, so we can focus on those?

If the project is small (both in number of team members and number of stories) you might be able to get away with rearranging story cards on the wall. However, in my experience, things inevitably get more complex. You often want to consider multiple factors when reviewing the backlog. A UXI Matrix helps you track and view these multiple factors.

Creating a UX Integration Matrix

The UXI Matrix is a simple, flexible, tool that extends the concept of the product backlog to include UX factors normally not tracked by agile teams. To create a UX Integration Matrix, you add several UX-related data points to your user stories:

Column Name	Possible Values	Description
Persona	Persona’s name	Identifies the persona a user story applies to
UX complexity	1 to 5 (or Fibonacci numbers if you’re into that sort of thing)	Estimates design effort separate from implementation effort
Story verified	Y/N	Is this story fiction or fact? Is it based on user research or customer input?
Design complete	Y/N	Is the design coherent enough for development to be able to code it (or estimate how long it would take to code)?
Task completion rates	0 to 100%	The percentage of users who have been observed to complete the story without any assistance.
Staffing	Resource’s name	Who’s owns the design, at whatever level of fidelity is agreed to.

With these columns added, your product backlog begins to look something like the spreadsheet in figure 1.

Figure 1: UX Integration Matrix, a simplified example

Advantages to using the UXI Matrix

The UXI Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process.

Groom the backlog

During release and sprint planning you can sort, group, and filter user stories in Excel:

Group by themes or epics, or anything you want to add via new columns
A primary persona, a set of personas, or number of personas associated (more = higher)
Stories you’ve verified via user research or ones you need to verify
Stories you’ve completed but need to refine based on metrics
Export stories into a format that can be used in information architecture work
Explore related UX deliverables like personas, mockups, and research findings via hyperlinks to them

Note the summary rows near the bottom of the example in Figure 1. Those values can help you prioritize new and existing stories based on various UX factors.

Reduce design overhead

Perhaps my experience is unusual, but even when I’ve worked on teams as small as seven people, we still had trouble identifying redundant user stories or personas. My heuristic is that if a story shares several personas with another story in a multi-user system, then that story may be a duplicate. Grouping by themes can also help here.

Another useful heuristic is that if a persona shares a large list of user stories with another persona, it’s likely the personas should be merged. Most of the time personas that do the exact same things with a product can use the same design, unless of course they have very different skills or something, which becomes evident when reviewing the personas or conducting user research (which all good personas are based on in my view).

Facilitate collaboration

“ The UX Integration Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process. ”

Another major benefit of the UXI Matrix format is you can share it with remote team members.

Listing assigned staff provides visibility into who’s doing what (see the columns under the heading Staffing). Team members can figure out who’s working on related stories and check on what’s complete, especially if you create a hyperlink to the design or research materials right there in the matrix.

For example, if there’s a Y in the Design Complete column, you can click the hyperlink on Y to review the design mockup. I’ve worked with teams who like to track review states here: work in progress (WIP), draft (D), reviewed ( R ), etc. (instead of just Y or N).

Track user involvement and other UX metrics

The UX Integration Matrix also helps track and share key UX metrics. One key metric to track is team contact with real end users. For example, if you’ve talked to real users to validate a persona, how many did you speak with? Another good metric is, how many users have been involved in testing the design (via usability tests, A/B tests, or otherwise)?

You can also capture objective, quantitative UX metrics like task completion rates, click/conversion rates, and satisfaction rates by persona. It makes it easier to convince the team to revisit previous designs when metrics show users cannot use a proposed design, or are unsatisfied with the current product or service. It can also be useful to track satisfaction by user story (or story specific stats from multivariate testing) in a column right next to the story.

Review UX metrics during sprint retrospectives

Scrum-style reviews and retrospectives are critical to improving both the design and team performance. However, few teams consider UX metrics as part of the retrospective. During these meetings, it’s helpful to have UX metrics next to the stories you are reviewing with the team.

I ask the team to answer these UX-related questions during the retrospective:

Did we meet our UX goals for the sprint?
1. Does our user research show that what we built is useful and usable?
2. Are users satisfied with the new functionality (new stories)?
3. Are users likely to promote our product or service (overall) to others?
4. Do we have product usage metrics (via site analytics) that meet our expectations?
Is there existing functionality (stories) that need to be refined before we add new stuff?
What user research should we do to prioritize stories going forward?
Do we have enough staff with UX skills to meet our objectives?
Going forward should we:
1. Work a sprint ahead to ensure we validate UX assumptions?
2. Do a spike to refine a critical part of the UX?
3. Refocus UX work on select user stories or personas?
4. Improve our feedback mechanisms to capture factors we are missing today?

Figure 2: The UX Integration Matrix inserts key user experience activities and context adjacent to user stories into the product backlog.

Improving your team’s design decisions

Once you start tracking in the UX Integration Matrix it becomes easier to have informed discussions during reviews and retrospectives. I use the UXI Matrix to set UX goals with the team, help prioritize stories in the backlog, track UX work in progress, and to help answer the classic agile problem “what does done mean”; not just for the entire product or service, but for individual stories.

I’d be curious to hear from others who would like to share their experiences with variations of the above or similar methods. On the other hand, if you’re an agile guy that thinks this all is very non-agile, I’ll ask “can you really prove your method creates a better UX without this stuff?”

Footnotes

[1] Larman, Craig. Agile and Iterative Development: A Manager’s Guide. Pearson Education, 2004.

[2] Sutherland, Jeff. “Agile Development: Lessons learned from the first scrum”. Cutter Agile Project Management Advisory Service, Executive Update, Vol. 5, No. 20, 2004: http://www.scrumalliance.org/resources/35.

[3] Cagan, Martin. Inspired: How To Create Products Customers Love. SVPG Press, 2010.

[4] Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley Professional, 2004.

[5] Cockburn, Alistair. Agile Software Development. Addison-Wesley Professional, 2001.

[6] Patton, Jeff; “It’s All In How You Slice It”, Better Software, January 2005: http://www.agileproductdesign.com/writing/how_you_slice_it.pdf.

Are Design Patterns an Anti-pattern?

Stephen Turbek — Thu, 26 Jan 2012 08:17:49 GMT

Design patterns are generally considered a good thing, but do they actually help run a user experience group? As a user experience group manager and an observer (and sponsor) of design pattern exercises, I’ve come to have serious questions about their actual utility. It’s not that design pattern libraries are bad, but that in a world of limited resources, it is it is not clear that the investment is worth it. Fortunately, there is a better approach: reaching outside the design group to solve the whole problem.

An interaction design pattern is a “general, reusable solution” “to common usability or accessibility problems”. They usually consist of pictures and descriptions of the best way to handle a GUI design element, such as a date picker. Libraries of them are found online (see below) and in many institutions with a user experience practice. Like all tools, they exist to solve a problem; but what is the problem?

They are generally said to help:

instruct junior user experience people
save time of documenting design details in every project
make collaboration with developers easier
encourage consistency

The case against design patterns

Pattern libraries have laudable goals, but in practice, design patterns do not support how teams actually work. Practically, the pattern approach assumes that the users:

know (and remember 3 months later) that the pattern library exists
quickly find the pattern that they need
know how to interpret the language
know when to apply a particular pattern and how much they can deviate
have the time and motivation to continue documenting ideas

Design patterns are not effective training tools.

Patterns, once literally a design on paper that could be copied, in UX are an abstract idea that professionals can reference. You can not copy a UX pattern, like you can copy a sewing pattern. Having someone read a pattern library will not make them a competent user experience designer. It would be akin to teaching writing by reading the dictionary – the “why”s are not answered.

Design patterns don’t replace UX expertise

Design patterns can be a useful reference point for the junior user experience designer. But experienced professionals find ideas and inspiration in the whole world. Should your team invest time in making a pattern library as a training tool, or just change the way they work? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer?

“ Should your team invest time in making a pattern library as a training tool, or just hire more experienced staff? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer? ”

Completeness and learn-ability are in conflict.

In order for a pattern to be used, it has to be easily read. But completely describing even the simplest UI pattern (like a two-panel selector) requires such detail as to prevent the person from absorbing it. Additionally, any design pattern I’ve seen inevitable contains “it depends” clauses, which leave the important decisions right back with the reader.

Pattern libraries suffer from a similar problem. Many seem to start by defining the basics, to answer questions like “when should one use radio buttons versus a drop down menu”, but lose steam before they get to the complex pieces. This is ironic, as the complex interactions are the ones that need the most definition, and offer the most creative opportunity. Defining the pattern of a radio button, is necessary for completeness, but not a good use of time or creative energies.

Design Patterns take a lot of investment.

The investment in the library needs to pay off in later efficiency to be successful. But each pattern is essentially a mini design project with extreme documentation and design reviews. Having corresponding template widgets is an additional effort, as is updating the designs when the inevitable rebranding comes along. (I’m already tired just writing this.) If your team uses more than one design tool (InDesign, OmniGraffle, Visio), who is going to update all the versions?

Design Patterns should help non – UX people first

Design patterns reduce work for UX people, but they clearly increase work for developers. Developers operate under time pressures and need a spec to code to. Directing them to look at a pattern library means that they have to find, parse, code, and review the pattern, in addition to the wireframe. The design pattern’s open ended nature requires them to read a general case and code a specific case. Because they are just designs, they can also ignore the ugly complexities in many of the problems, by simply not addressing them.

Design Patterns don’t work with a normal designer’s motivation – indeed, they seek to restrain it. When a person sits down at their drawing program to address a problem, a reference document is several steps away, especially under time pressure. They almost always want to design rather than copy, especially, when it is unclear if a new situation is different “enough” from an existing pattern. On the contribution side, any change will entail a review with peers, which could take weeks to finalize, too slow for a project. Large organizations who most need a pattern library (many practitioners) are least able to build one (complex organizations, conflicting deadlines).

Why do people make design pattern libraries anyway?

I’ve never heard of a business owner or technology lead asking for a design pattern library. They seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal?

Pattern libraries seem to be made by a UX person who wants to put a stamp on how things SHOULD be done. To establish, once and for all, the right way to do something. The design pattern library could be more akin to building a model train set: like the real world, but controllable. They are like design projects without clients or time pressure. “Just this once, we’ll do it perfect”. A participant at a recent New York IXDA event said with pride that he personally had created several pattern libraries –it was a personal accomplishment, not a business achievement. No one can argue with how a person spends their free time, but teams have to make sure work time is spent wisely.

The downside to this motivation is that individual authors want to create their own collection, which inevitably duplicates the other libraries. Pattern Libraries also tend to be abandoned when the author loses enthusiasm after the initial burst of activity. Even the major sites like Yahoo and Welie have stalled. The last update on Yahoo was 2 years ago; Welie was 4 years ago.

“ [Pattern libraries] seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal? ”

What is the solution then?

Let’s apply the user centered design process to this situation. Using the goal of “better designed products and increased productivity”, we can identify the three potential audiences of an enterprise Pattern Library: User Experience, the Business representatives, and Technology.

The UX group is primarily concerned with consistency and best practices. This is culture, not documentations and should be managed as such:

Culture is built through personal interaction. Review, Review, Review. Regularly meet to share work, and best practices.
Patterns do not mean your design sense can go on auto-pilot.
Build a collaborative culture referring each other’s work. (“Joe worked on something like that.”)
When a new design challenge appears, get a bunch of people to talk it over, get “good enough” agreement.
Document decisions quickly and spread widely, for example on a wiki (so any one can edit it).
Focus on content first, make the pretty library template as a reward for reaching 20 patterns.

Business and Technology are primarily concerned with getting work done and reducing costs. The biggest efficiency gain is reducing development time, focus on giving developers the tools and guides they need. The biggest issue is that typically, UX people do not code. The solution is to get out of the design cave and work with people who do.

Create a design ecosystem instead of documentation.

People do not RTFM. Period. It is hard to get people to engage with any documentation on their own. They are happy to read the details about what they want, but are put off by finding it inside a large document or library. The solution is to create an ecosystem where each piece reinforces the others. iPods were well-designed devices, but they succeeded because of the ecosystem (devices +iTunes + stores + accessories). Music was easy to find and buy, and easy to put on the computer. The overall experience of the ecosystem is what determines the success. When you say the answer is a document, rather than a community, it turns people off and limits their contribution.

The ecosystem should be composed of:

People: Developers, Designers, and business leads. People who can answer questions, who are motivated by their own job requirements and professional pride
Code library and documentation
Management demand

A code library beats a pattern library

The code library should be “internal open source”, a shared library enabling developers at a company to share code without worrying about licensing or malware. Instead of the whole org waiting while a centralized team builds the future, let every group contribute.
It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests, supported by an active development and UX mail lists. Make them easily accessible as web pages, not a document. Style guides and pattern libraries get retained even if they are out of date. Social connectivity is much more important than printing them out.

It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests. This is supported by an active development and UX mail lists.

For each presentation layer technologies you support, there should be in Version Control system, with a Main branch, supported by a core team, and an open Contrib branch that anyone can put components in. Good components are promoted to the main branch, which is released in versions, so updates do not break existing apps.

Components should cover three scales:

Basic styling of standard components
Custom components, like a date picker or type-ahead
Page sized components, such as forms,dashboards, or search result pages

“ Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone. ”

How do you get such a library?

In a world of limited resources, one has to boot-strap the Library.

Build off of the current running projects. Nominate widgets or functions in an active project as “library-worthy” and have them coded abstractly and contributed to the library.
Publish and reward people who contribute to the library.
Make a most wanted list and see who has them.
Solve problems that you actually have, don’t worry about completeness.
Have the patterns in working code samples accessible by anyone in the firm. Instead of pretty pictures, have the code that actually performs how your want it to. Make the options / parameters editable in the sample, so anyone can play with configuring the sample.
Look and feel should be a separate code library, released in parallel, so that the design can be upgraded in the future (as it will be) without affecting functionality.
For general guidelines, write high level guidelines a sketch or two, but point the developers to ask a mailgroup of designers and front end engineers. When a question gets asked enough that it is annoying, code the pattern.

Management support is critical -if the project is a “nice to have”, it is doomed. Each project should report what they contributed to the library and what they consumed. A developer’s performance evaluation should list what they contributed to the library and what they re-used -Both save the firm money. At a firm I worked at – a single component, taking 2 weeks of two developers’ time, was re-used over 200 times. This saved 16 person-years of effort -this is real money. Not every component will be so effective; the library team should be focused on the business value of each component and the user experience of the eco system. If done right, the design / code ecosystem has the potential to both improve design and save time, something we can all agree on.

Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone. Working together with non designers can make everyone’s life easier, and make the final product as good as the design.

Complexity and User Experience

Jon Bolt — Wed, 23 Nov 2011 07:13:38 GMT

The best products don’t focus on features, they focus on clarity. Problems should be fixed through simple solutions, something you don’t have to configure, maintain, control. The perfect solution needs to be so simple and transparent you forget it’s even there.

However, elegantly minimal designs don’t happen by chance. They’re the result of difficult decisions. Whether in the ideation, designing, or the testing phases of projects, UX practitioners have a critical role in restraining the feature sets within our designs to reduce the complexity on projects.

Why you should reduce complexity in scope

Over-designed and complex products typically stem from a ‘more is better’ philosophy. Expanding the feature count beyond what’s truly needed is perceived to increase the overall value. Essentially, increasing scope has connotations of giving your audience flexibility. Equally, reducing scope implies you’re limiting your customers.

If we begin to discuss scope as complexity, instead of flexibility, it changes the conversation as it reinforces there’s a correlation between the two. Indeed, they’re really the same thing. Complexity is scope. Every new feature creates additional guesswork. To put it bluntly, increasing scope means there’s more opportunity to screw things up.

“ If we begin to discuss scope as complexity, instead of flexibility, it changes the conversation as it reinforces there’s a correlation between the two. Indeed, they’re really the same thing. Complexity is scope. ”

As well as making things more difficult upfront, unnecessary features set up additional complexity with future releases. This is because the user interface groundwork early in projects establishes constraints. We have to live with the consequences of our initial design decisions through future iterations. So a tight focus on features early on is crucial. The alternative, trying to solve too much too soon, means initial design decisions become high risk.

As well as reducing the technical complexity, an elegantly minimal feature set clarifies the proposition of your product and simplifies the experience for the user. Any feature that doesn’t help solve problems for your audience should be thought of as a distraction, an unnecessary obstacle that undermines the value of your product.

Properly defining scope

Where to define the scope isn’t easy. Different users will have varying requirements. There’s also the grey area, where removing functionality can result in a drop in the value and revenue of your product.

Also, simplifying a design to reduce it’s perceived complexity doesn’t always work and can create significant barrier for users. A good example is financial software, where the user interface is built around tasks which are inherently complex.

However, simply because a task is complex doesn’t create an excuse for designing a complex user interface or user experience. We should architect solutions around how much control is truly needed. Truly exceptional experiences are crafted when complexity is removed whilst the level of power and control is maintained.

Preventing scope creep

Once your initial scope (or the level of complexity you’re comfortable with adopting) has been defined, the best approach is tackle one feature at a time. Design the first iteration around the most critical and well understood problem.

From this approach additional features can often feel like a simple and natural extension, an easy way to make extra revenue. Despite the sometimes low cost of designing additional features, there are hidden costs.

“ Additional features can often feel like a simple and natural extension, an easy way to make extra revenue. Despite the sometimes low cost of designing additional features, there are hidden costs. ”

Unnecessary features are a distraction for developers and designers. They draw people away from optimizing the little details or other things you could be doing to help your existing customers. They also dilute the core proposition of your product and the prominence of the most important features.

Clearly understand what new features you need to add and what the implications of developing them are. Classify features into mandatory and nice to have and the put all the mandatories through a review to ensure they really are mandatories. Ultimately, you have to accept there’s a gray area where, as you strip out features, the expected revenue will fall.

Why you should reduce internal design complexity

Complexity cannot simply be expressed by feature creep. It can still exist within a minimal viable product, as features themselves can behave in unnecessarily complex or unconventional ways.

Despite successfully restricting a tight constraint on features to an elegant minimum, we need to think about the complexity of the features themselves. This can lead to instances where the most appropriate remedy to internally complex features is an additional feature.

Here’s an example. On a recent project, a client insisted on an autosave function for a particular part of an interface when the addition of a save button would have made the interaction and its outcome much more intuitive to the user (as testing later confirmed).

The increased complexity of expanding the scope of the minimum viable product was offset by the decreased internal design complexity of aspects of the system’s technical and user interface.

So, a minimal feature set doesn’t necessarily translate into a simplified user interface. Cumbersome interactions or poorly designed user journeys can easily offset the benefits of removing unnecessary features. Equally, it’s sometimes necessary to expand the system’s scope to to reduce the internal design complexity of certain features.

Managing internal design complexity

Managing ‘internal design complexity’ relies upon a paradox. The phrase implies the complexity of any given single feature. However, the significance of ‘internal’ complexity is not constrained to a single feature. Managing internal design complexity requires us to assess the solution at two levels simultaneously. Only through critical end-to-end analysis of the solution can we make a similarly effective judgement about whether any single feature is as simple as it can—or crucially—should be.

When looking at a feature set and deciding what can be safely eliminated without endangering core goals, reductionism is a double-edged sword., Taking the simpler view inherent in the ‘Minimal Viable Product’ mentality will result in cleaner, easier, more elegant and achievable designs. No less regularly, however, the process of reduction blinds us to unseen compromises in the functional simplicity of the solution as a whole.

The broader, zoomed out view may actually guide us to adding function to a feature here or there, all in the service of simplicity at the more general level.

Take the above example of the autosave function: the complexity of correctly intuiting the behavior of this single feature is one thing. Adding a function to the feature reduces the chance of the feature being misunderstood or misused. Beyond that, however, it would also have ensured that the instance of counter-intuitive behavior does not set precedents for how the wider solution is perceived.

This is the paradox: you can have the most elegantly minimalist feature set imaginable, but you will not attain simplicity if you don’t apply the principle of simplicity both holistically and flexibly. Features that are simple in isolation can become a contagion.

Conclusion

A core difficulty with discussing complexity and user interfaces is that it’s easy to misclassify the level of complexity. It’s a qualitative concept. As such, it’s important to keep a check on the subjective nature of our discussions. We have to be aware that complexity can only be reduced to a particular point, past which designs can lose both their utility and appeal.

It’s also not whether a design approach is more or less complex. The issue is that we’re talking about the experience of the system, not a quantitative measure of complexity. Ultimately, to determine the impact of scope complexity and internal design complexity across the overall user experience, complexity needs to be understood within a context.

The result is that many of the discussions on complexity and simplicity are polarized around whether or not complexity is an additive property. But, perhaps there’s nothing wrong with that, you should have a clear opinion on the products you make. Software should have your personality ingrained within it.

Alignment Diagrams

James Kalbach — Wed, 07 Sep 2011 18:40:37 GMT

Did you ever get bounced around between departments when interacting with a company or service? This happened to me recently with my credit card: the card issuer and the bank backing it seemed to disagree who was responsible for my problem. Each blamed the other. I got caught in the middle.

My communication with them also crossed multiple channels. For some things I used their website, for others I had to call. There were emails, regular mail and even a fax involved as well. None of it seemed coordinated. Apparently it was my job to piece it together. Bad experience.

Why does this happen? All too often companies are focused on their own processes, wrapped up in a type of organizational navel gazing. They simply don’t know what customers actually go through.

What’s more, logical solutions can cross departmental lines. Ideal solutions may require crossing those boundaries. An organization’s rigid decision making makes that difficult.

Here’s where I believe IAs and UX designers can use our skills to make a difference. We have the ability to understand and to map out both business processes and the user experience. Visual representations can provide new insight into solutions that appeal to a range of stakeholders. Alignment diagrams are a key tool to do this.

Mapping The Experience

“ Alignment diagrams reveal the touchpoints between a customer and a business. Illustrating these helps a company shift its inward-focusing perspectives outward. Alignment diagrams make the value creation chain visible. ”

The phrase “alignment diagrams” describes a class of documents that reveal the touchpoints between a customer and a business. These touchpoints are organized and visually aligned in a single graphical overview. Illustrating these touchpoints helps a company shift its inherently inward-focusing perspectives outward. Alignment diagrams make the value creation chain visible from both sides of the fence.

Alignment diagrams are not new. In fact, you’ve already used them. Thus my definition of alignment diagrams does not introduce a new technique but rather recognizes how existing techniques can be seen in a new, constructive way.

Alignment diagrams have two major parts. On the one side, they illustrate various aspects of user behavior—actions, thoughts, and feelings, among other aspects of their experience. On the other side, alignment diagrams reflect a company’s offerings and business process in some way. The areas where the two halves meet gives rise to touchpoints, or the interactions between customers and an organization.

Below are examples of two diagrams that illustrate the alignment principle.

Example 1: Service Blueprint

The first example is a service blueprint created by Brandon Schauer of Adaptive Path (Figure 1.). This shows the chronological flow of steps for attending a live event, in this case a panel on service design. (See the original details of the event from 2009 ^[1]).

The top two rows show the phases and physical devices a participant might use. We can call this the “front stage.” The bottom three rows show the activities of the organizer. These are “backstage” activities. These two parts are separated by the “line of interaction,” or touchpoints between participants and organizer of the event.

Figure 1: An example of a simple service blueprint by Brand Schauer, Adaptive Path

Example 2: Mental Model Diagram

The next example of an alignment diagram is a mental model. Indi Young developed this technique and detailed it in her book Mental Models (Rosenfeld Media, 2008) ^[2].

Figure 2 is a slightly simplified version of a mental model diagram, but it shows the alignment principle well. This example shows a mental model for activities related to “getting up in the morning.” The top half hierarchically arranges user actions, thoughts and feelings gleaned from primary research. These are clustered together into broader “goal spaces” (e.g., “Get Dressed”).

Below the center horizontal line are products and services that support people in these activities. With this alignment, providers of goods and services can see where they address user needs and where there are gaps.

Figure 2: An example of a mental model diagram by Indi Young, reflecting the alignment principle.

There are other visual styles and approaches to alignment diagrams beyond the above figures. (See the list of Alignment Diagram resources at the end of this article.) Customer journey maps and workflow diagrams are also examples. So there is no single approach to the alignment technique. Instead, you choose the form, the information included, and the way you present them to shape your overall message. It depends on your situation. The important thing to remember is that an alignment diagram shows user behavior aligned to business activity to reveal touchpoints.

Locating Value

“ An analysis of the touchpoints between users and the business lets us see value creation from both sides of the equation at the same time. This is at the core of the alignment technique. ”

Businesses ultimately need to earn money. But to do so they also have to provide some value to customers. An analysis of the touchpoints between users and the business lets us see value creation from both sides of the equation at the same time. This is at the core of the alignment technique.

In a previous Boxes and Arrows article entitled “Searching for the Center of Design,” Jess McMullin proposes what he calls “value-centered design.” ^[3] Instead of focusing solely on the business or solely on users, Jess advocates focusing on how value is created for both. “Value-centered design” is the approach he prefers. He writes:

The basic premise of value-centered design is that shared value is the center of design. This value comes from the intersection of: business goals and context, individual goals and context, and the offering…and delivery.
Value-centered design starts a story about an ideal interaction between an individual and an organization and the benefits each realizes from that interaction.
Jess McMullin, “Searching for the center of design”, Boxes and Arrows, 2003.

Alignment diagrams let us tell the story of value creation.

Once completed, alignment diagrams serve as diagnostic tools. With them we can spot and prioritize areas for improvement. They also point to opportunities for innovation and growth. Ultimately, alignment diagrams let designers capture and reflect how value is created in a holistic way. When communicated to decision makers, this can have real business impact by changing the focus from how products are made to the experience customers have.

Who Creates Alignment Diagrams?

“ Modern business challenges are wicked problems. Organizations unknowingly pass this complexity on to customers, resulting in negative user experiences. Alignment diagrams can reduce complexity for both customers and for organizations. They are an antidote to the challenges our business partners face. ”

The good news is you probably already have the skills needed to create alignment diagrams. These include:

1. Conducting Research

Alignment diagrams are not made up. They are based on real data. Face-to-face interviews and observation work best. This includes contacting people on the business side: stakeholder research is part of the alignment technique.

2. Synthesizing Findings

Designers are good at describing abstract concepts, such as an intended experience. We’re able to empathize with users and summarize their perspective well. And we can communicate this back to our business partners in a way they can understand.

3. Visualizing Information

Alignment diagrams are visual stories. Designers are good at representing ideas in graphic form. The visual nature of alignment diagrams makes them compact and immediately understandable.

4. Brainstorming

Alignment diagrams serve as an excellent stimulus for a workshop or brainstorming session. Designers have the skills to creatively brainstorm and lead such sessions.

5. Prototyping Solutions

Exploring different directions is a key aspect of “design thinking.” Designers are well-versed in trying out different options—from sketching to wireframing to prototyping.

Keep in mind that the lines between design-related disciplines are blurring. Service designers increasingly use online services and digital kiosks in their concepts. UX designers must be able to integrate offline support and services into their solutions. IAs need to be able to structure information across channels, including physical spaces. Interaction designers must conceive of workflows and actions across media types and devices.

In the end, alignment diagrams aren’t the domain of one field or the other: they can inform any field. The skills needed to create them, listed above, cross these lines as well.

Getting Started

“ Alignment diagrams start a conversation towards coherence, bringing actions, thoughts, and people together to foster consensus. More importantly, they focus on creating value—for both the customer and the business. ”

Understanding the mechanics of alignment diagrams is fairly straight forward. The hard part is getting your foot in the door. Often designers aren’t called in until after a project is already set up. Alignment diagrams, however, really need to impact decisions much earlier in the process—before a project even starts. This means you need to “swim upstream” and reach out to a potentially new set of stakeholders.

For designers in internal teams, you may have access to managers, product owners and other executives who could benefit from alignment diagrams at a strategic level. For external consultants, pitching a case for an alignment diagram effort may be harder: reaching high-level decision makers is difficult. Either way, you’ll need to effectively evangelize alignment diagrams in order to get the time and money to complete one.

Here are some things you can do to get started:

1. Learn about alignment diagrams.

Start by reading books like Indi Young’s Mental Models. Or, check out things like my resources on customer journey mapping on the web ^[4]. I also have a presentation ^[5] and an article ^[6] coauthored with Paul Kahn specifically on alignment diagrams.

2. Sketch draft diagrams for your current project.

What story could you tell on your current project to show where customer value and business value is located? How would best visualize that story in a diagram? Even without any official project scope or user research, you can sketch out a rough map showing the facets of information you’d include, where alignment occurs, and how you would visually convey your message. This is practice in understanding the alignment technique.

3. Complete an alignment diagram “under the wire.”

A formal alignment diagram must be based on real evidence. But this evidence could come from a variety of sources. A high-level customer journey map, for instance, could be created with data from existing research. Or, try adding a few simple questions your next usability test to understand users’ interaction with a service. Create a draft diagram from this data as you do other types of analysis. Present this to stakeholders. It’s likely they’ll find it interesting and ask for more.

4. Find a champion in management.

Seek out business partners who might “get” alignment diagrams. Discuss the possibility of a pilot project with them. For the cost of a normal usability test, for instance, you could create a simple alignment diagram. Unlike outcomes from other types of research, such as marketing studies or usability tests, alignment diagrams do not change very quickly. Be sure to highlight the longevity of an alignment diagram effort to sponsors, and remind them they’ll be able to refer to the information years later.

Conclusion

Truth is, the business world is becoming increasingly complex. Studies in business complexity show that leaders are unable to cope: they are pulled in different directions and unable to focus ^{[7, 8]}. Modern business challenges are wicked problems. All too often, organizations unknowingly pass this complexity on to customers, resulting in negative user experiences.

While they do not guarantee success, alignment diagrams can reduce complexity for both customers and for organizations. They are an antidote to the challenges our business partners face. At a minimum, alignment diagrams start a conversation towards coherence, bringing actions, thoughts, and people together to foster consensus. More importantly, they focus on creating value—for both the customer and the business.

Designers can use their skills to map out value creation and help solve business problems. Empathizing with users and illustrating out their experiences plays a big role. Visualizing touchpoints provides an immediate “big picture” often lacking in many organizations. This can provide a much-needed shift of attention from inside-out to outside-in. Alignment diagrams are a class of documents that seek to address the causes of poor experiences at their roots and ultimately help designers have a real business impact.

Footnotes

[1] Brandon Schauer, Service Blueprint, http://adaptivepath.com/ideas/this-thursday-in-sf-service-design-panel-kicker-kickoff

[2] Indi Young, Mental Models (Rosenfeld Media, 2008). http://rosenfeldmedia.com/books/mental-models/

[3] Jess McMullin, “Searching for the Center of Design,” Boxes and Arrows (Sept 2003). http://www.boxesandarrows.com/view/searching_for_the_center_of_design

[4] James Kalbach, “Customer Journey Mapping Resources on the Web.” http://experiencinginformation.wordpress.com/2010/05/10/customer-journey-mapping-resources-on-the-web/

[5] James Kalbach, “Alignment Diagrams: Strategic UX Deliverables,” Euro IA Conference (Paris, 2010). http://www.slideshare.net/Kalbach/james-kalbach-alignment-diagrams-euro-ia-2010

[6] James Kalbach and Paul Kahn, “Locating Value with Alignment Diagrams,” Parsons Journal of Information Mapping (April 2010). http://piim.newschool.edu/journal/issues/2011/02/pdfs/ParsonsJournalForInformationMapping_Kalbach-James+Kahn-Paul.pdf

[7] IBM, “Capitalizing on Complexity,” (2010). http://www-935.ibm.com/services/us/ceo/ceostudy2010/

[8] Booz & Co, “Executives Say They’re Pulled in Too Many Directions and That Their Company’s Capabilities Don’t Support Their Strategy,” (Feb 2011). http://www.booz.com/global/home/press/article/49007867

Are your users S.T.U.P.I.D?

Stephen Turbek — Wed, 20 Apr 2011 07:22:58 GMT

It is an honest question: how smart are your users? The answer may surprise you: it doesn’t matter. They can be geniuses or morons, but if you don’t engage their intelligence, you can’t depend on their brain power.

Far more important than their IQ (which is a questionable measure in any case) is their Effective Intelligence: the fraction of their intelligence they can (or are motivated to) apply to a task.

Take, for example, a good driver. They are a worse driver when texting or when drunk. (We don’t want to think about the drunk driver who is texting.) An extreme example you say? Perhaps, but only by degree. A person who wins a game of Scrabble one evening may be late for work because they forgot to set their alarm clock. How could the same person make such a dumb mistake? Call it concentration, or focus, we use more of our brain when engaged and need support when we are distracted.

So, what does a S.T.U.P.I.D. user look like?

Stressed

“Fear is the mind killer”, Frank Herbert wrote. Our minds are malleable and easily affected by their context. The effect of stress on the brain is well known, if not well understood. People under stress take less time to consider a decision thoroughly, and they choose from the options presented to them rather than consider alternatives. Stress is often due to social pressures. Car salespeople know to not let a customer consider an offer overnight, but pressure them to buy right away.

Tired

Tiredness is one of the largest causes of industrial and motor vehicle accidents. Interfaces used by tired people should take into account their lowered sense of self-awareness and number of details that the user is likely to miss. A classic example of an interface used by sleepy people, the iPhone alarm clock is typically set right before bed. Unfortunately, it doesn’t ring if the phone is set to vibrate, the default state for many people. When a user sets the alarm, it would be useful to override the vibrate feature, or at least remind them that it won’t ring.

Untrained

Training for enterprise applications is more often discussed then enacted. Users are thrown at an application with a manual and a Quick Reference Card. Applications that are not designed around the user’s workflow have to explain their conceptual model while they are being used: “where” things are stored, how to make changes, who to send things to.

Complex systems that are used infrequently are a particular problem. In the design of the automated external defibrillator, it is assumed the user may have no knowledge of the science or training on the device, and will be using it in a chaotic, stressful environment. The frequency of use should drive design. Yearly processes, like doing your taxes, should assume that the users have never done it before. In rarely used interfaces, customization is likely to be less useful, but a comparison to previous year’s entries is very useful as they remind the user what they did before.

Passive

“ Nothing reduces effective intelligence faster than doing a boring task against one’s will. ”

More important than the user’s mental model of an application is their mental attitude toward the task. Someone sitting in the front passenger seat of a car may have the same field of view as the driver, but unless they are focused on it, they will not remember the path driven. Nothing reduces effective intelligence faster than doing a boring task against one’s will. When a user is passive, complexity becomes insurmountable. Games aimed at casual gamers know to keep the interaction model simple, using a flat navigation and avoiding “modes” (e.g. edit vs view).

Independent

User centered design is a powerful approach because it recognizes that there are many reasons people use a system. Airline booking sites are used to buy tickets, but also to see if the family can afford to go on vacation. The designer should recognize that they cannot solve every problem, but should give users the tools to help themselves, to work independently of the application’s intended method. In internal enterprise systems, the top user request is often “export to Excel”. This often reflects that the system does not meet the user’s needs. Excel empowers the user to do ‘out of the box’ actions. It is the API to the real world.

“ ...The top user request is often ‘export to excel’.... Excel empowers the user to do ‘out of the box’ actions. It is the API to the real world. ”

Distracted

People are multi-tasking more than ever, whether it is simply listening to music while driving or playing Farmville while watching TV. Effective multi-tasking has been shown to be a myth, but it is a popular one. Paying “partial attention” to multiple activities has significant impact to your perception of an interface. Users are often said to be on “autopilot”, clicking on things by shape, rather than reading the text. An interface cannot rely on the user having a clear and consistent working memory across multiple screens. The task and details must be re-stated at each step to remind the user the step they are on and what they need to do. Frequent, automatic saving of user entered data is essential, especially as connections can time out.

Help S.T.U.P.I.D. users by designing S.M.A.R.T.

Start-ups often experience a shock when they emerge from the hothouse of heads-down development. Their intended customers barely have time to listen to their idea, let alone devote time to explore its features. The contrast between a small group of friends working intensely together on a single project with the varied needs and limited free time of their customers can be a disheartening experience.

Projects often fail not because the idea is bad, but because the value their service will provide is not easily understood. The question I ask my team is “What problem, from the user’s point of view, are you solving?” It has to be a problem the user knows they have. If the problem is not obvious to the user, in terms they understand, the solution doesn’t matter. Focusing on the problem keeps a project from drifting into fantasy requirements: solutions looking for a problem.

“ Design teams often use themselves as model users, but…. The user knows nothing about the product, doesn’t understand the concept, and doesn’t care. ”

Design teams often use themselves as model users, but they are almost the perfect storm of differences between themselves and the users.

They know the product exists and what it is supposed to do.
They understand the internal concept, including its past and future ideas.
They care, personally, about the product. Their success depends on it.

The user has none of these things. The user knows nothing about the product, doesn’t understand the concept, and doesn’t care.

What can be done to make S.T.U.P.I.D. users S.M.A.R.T?

Simplify

Why are simple apps popular these days? It is not that people don’t like features, it’s because instant comprehensibility trumps powerful features. In the old search engine wars, Google may have had a better search algorithm, but they became known for having a simpler design. Yahoo and others tried to become portals, losing sight of the users primary goal. I advise people to “Design the mobile version first” to help them focus on the key user benefits.

The down side is that any successful project expands and adds features to address additional user needs. What starts out as “Writer for iPad” can end up as Microsoft Word. Simple is not always better, but keeping the new user in mind helps find the right balance.

Memorable

An app is only as good as the user understands it. That starts with the name – is it cute or does it explain what it does? Is it “pidg.in” or “Automatic Mailbox”? The iPhone / iPad apps’s television ads were effective sales tools, but also trained a generation by simply showing them in use. Each step of a workflow is subject to delays and distractions. Ecommerce sites know to reduce links during the final checkout process. With complex transactions, the risk is greater that the user will have lost their focus. Remind the user what they are doing in big title text. Focus on delivering Clear and Consistent messaging and instructions, for example, adding side notes like Ally.com’s password guidance.

Accept Autopilot

Standard design patterns are good, but they also throw the user into autopilot. It makes sense to break them for critical decisions. The hard part is determining what a critical decision point is. Observing user behavior, customer service records, and identifying risks to the user’s data are good clues. If something is simple enough that the users are mostly on autopilot, for example installing software, make the default action a single click.

Recovery

The dark side of users on “autopilot” is that they will regularly make mistakes by not paying attention. Mistakes are generally not obvious to a system, but it is good practice to highlight destructive actions and enable recovery. Capture data in little steps. Saving form fields instead of form pages, prevents large data loss. It’s a good idea to highlight and ask for confirmation on big, destructive changes, like deleting a database. “Undo”, common on computers, but slow to come to the web, enables the user to recover from errors.

Gmail lets users undo moving a message to the trash.

Gmail also let you restore your contacts if you accidentally make a large, destructive change.

Test in realistic situations

There is an essential flaw in the two-way mirror usability test method. In the interest of copying the form of the lab-coated scientist, these rooms create an artificial aura of “science”. But as ethnographic research can tell you, real world usage is so different as to make the test questionable. It selects for a test population that is free in the middle of the day, motivated by $50, and M&Ms, puts them in an unfamiliar environment with a personal guide to focus on a specific task with no distractions. This is about as unrealistic as it gets.

“ There is an essential flaw in the two-way mirror usability test method…. It selects for a test population that is free in the middle of the day, motivated by $50, and M&Ms. ”

In reality, the same person may have a child on their lap and only 10 minutes to look up a flight. The fact that an ecommerce session may expire after a few hours is trivial for some, but significant for people who only have a few hours a day to use the computer. “Universal Design” is a great approach, because methods to help specific disabilities tend to be useful to the general public.

Testing should go beyond the user interface and cover the basic business model. The Apple iTunes video download “rental” is for 24 hours. Unfortunately, people tend to watch movies at the same time each day, for example, after the kids go to bed. If your kids wake up, you have to finish it earlier the next day. Would it have killed them to make the rental 27 hours, so parents could actually use it?

Design for the right level of Effective Intelligence

Effective intelligence obviously varies across situations. People are ingenious at figuring out things they really want, but the simplest task is insurmountable to the unmotivated. Both scenarios are solvable, but an application that makes the wrong assumptions about its users will fail. (Interestingly, this study suggests that easier-to-use design can affect the user’s perception of difficulty, and encourage them to complete the task.)

One should adapt their strategy to the user’s desire and the problem’s complexity. Here’s an unscientific matrix for effective intelligence with software interfaces.

This matrix compares the amount a user desires to complete the task versus the complexity of the task to that user type. Different user types will have different measures of complexity, so one might create several matrices.

Low Desire, Low Complexity – The goal here is to finish these tasks as fast as possible. Follow standard design conventions, seek to eliminate steps.

Low Desire, High Complexity Complex – Tasks that the user doesn’t want to do are a danger zone. Can the problem be reconsidered or eliminated?

High Desire, Low Complexity – The easiest quadrant.

High Desire, High Complexity – This is the most interesting quadrant. A self-training interface, (integrated help, training modules) can get the user started; they will often take it the rest of the way. Video games often have a “training” level to train the user on basic skills like moving around.

Get Smart

Effective Intelligence is a helpful concept in the design toolbox. User research and testing are the best ways to know your users, but knowing what may limit a user in reality helps design ways to make them smarter.

Like this article? Want to keep Stephen’s wisdom close at hand? Download the handy, cubicle-friendly, 61kb PDF to hang on a nearby wall and you’ll always remember to design SMART.

Novices Orienteer, Experts Teleport

Tyler Tate — Wed, 20 Apr 2011 07:22:28 GMT

Would you rather take a photo using your phone, a point-and-shoot camera, or a digital SLR? How you answer this question is probably a good indicator of your photographic expertise. If you snap casual shots, your phone or a point-and-shoot camera will probably suffice. If you’re a professional photographer, on the other hand, you probably prefer using an SLR that gives you control over the focus, aperture, and exposure.

Expertise significantly impacts how we seek information online. Just as novice and expert photographers prefer different tools, so novices and experts behave differently when searching for information. Understanding these differences will help us design better search interfaces for both groups of users.

h2. There are experts, and then there are experts

User expertise exists on two levels. If you’re an avid photographer, your domain expertise in photography will be quite high: that is, you’ll be familiar with the terms and techniques of the trade. Each of us is likely a domain expert in a few areas, and a complete novice in others. A second aspect is technical expertise. Familiarity with how computers, the internet, and search engines work significantly impacts how users seek information. Consider these personifications of each quadrant of expertise:

* *Angela Baer*, since completing her MFA at Pratt 5 years ago, is quickly building a reputation as one of New York’s up-and-coming fashion photographers. In the office connected to her studio, Angela edits her photographs on two large monitors and top-end computer. She delivers the edited shoots electronically to her clients, and regularly updates her online portfolio and blog. Angela is highly proficient using her computer, and when it comes to photography, she’s a domain expert.

* Though officially retiring over 10 years ago after a successful career in banking, *William Hayes* still sits on the board of a number of financial institutions. From his Elizabethan cottage on the Kent coast, he uses a 5-year old computer to exchange emails and access financial reports, though he prefers doing business on the phone and keeping up with the world though The Financial Times. While William is a domain expert when it comes to finance, his technical expertise is lacking.

* 18-year-old *Fane Tomescu* helps run an internet cafe in Braşov, Romania. Having saved for over a year, Fane recently came across a car that he’s considering purchasing. But when the time came to arrange car insurance, Fane had no clue how things worked. He asked his parents and friends for advice, and then spent several hours comparing providers online. Fane is a technical expert, but when it comes to insurance, he’s a domain novice.

* *Claire Jones* is a 9-year-old from Colorado Springs. Her school is holding a science fair and Claire has decided to build a model of the solar system using styrofoam balls suspended with string. Having left her science textbook in her locker over the weekend she was meant to start building the model, Claire used the internet to lookup information on the order, size, and appearance of each planet. Though she did eventually find what she was looking for (with her parents help), Claire would be considered both a technical and a domain novice.

While either dimension of expertise is valuable, users are most likely to succeed when both are present. There are, however, a number of design guidelines which can help both novices and experts succeed in their pursuit of knowledge.

h2. Novices Orienteer

Image 2: An orienteer at the 2010 World Orienteering Championships in Trondheim, Norway. Photo by Torben Utzon.

Wayfinding is a challenge as old as humankind, but the discipline of orienteering originated in the Swedish military in the 1800s and is now a sport practiced throughout Scandinavia. Equipped with a map and compass, participants navigate between control points spread across many miles, making tradeoffs between distance and difficult terrain as they strive to complete the course in the shortest amount of time.

The strategies employed by novice users seeking information resemble the sport of orienteering. [1] Users with low levels of domain and technical expertise, typified by Claire Jones, share three main characteristics.

h4. Short queries

Novices tend to enter queries that use about half as many words as experts.[2] Domain novices (like both Claire and Fane Tomescu), feel particularly unsure of which terms to use.

h4. Many queries

Novices perform more queries than experts, but look at fewer documents. Although they frequently reformulate their query, technical novices often suffer from an anchoring bias [3] and make only small, inconsequential changes.

h4. Going back

Novices are much more likely than experts to hit dead ends and seek to get back to a previous state.

These behaviours result in an orienteering-like strategy where novices “test the waters” with a short, general query, quickly skim the top results returned, and immediately reformulate the query based on their improved knowledge of the subject. [4]

h2. Design considerations for Novices

There are a number of design considerations which can help novice users succeed at orienteering. In particular, novices need help formulating their query, refining their query, and backing out of trouble.

h4. Autosuggest

As-you-type suggestions can help users get off on the right foot when they’re uncertain what to search for. Research has shown [3] that users are more capable of choosing a viable option from a list than they are of composing a question out of thin air. Autosuggest provides an opportunity to help users express specific terms (such as airports or stocks), and to suggest queries that other users have performed in the past.

Image 3: Autosuggest on Etsy.com

h4. Related searches

After users have performed an initial search, they may still need help refining the query. A list of related searches can help the user break out of their anchoring bias and help them arrive at the optimal set of results.

Image 4: Foodily.com place related searches on the same line as breadcrumbs

h4. Avoid zero results

If the user is presented with no search results, he may be disheartened enough to give up his quest. Avoid zero-result screens if possible. Tools such as automatic spelling corrections and query expansion (using synonyms and lemmatisation,[5] for instance) can help.

Image 5: Amazon.com’s handling of zero results

h4. Breadcrumbs

Because novices tend to take wrong turns, they often need help navigating back to a previous state. Breadcrumbs are an ideal solution because they communicate both the user’s current location, as well as how to go back.

Image 6: Breadcrumbs on Zappos.com

h2. Experts Teleport

Image 7: In Star Trek, crew members of the USS Enterprise stand on transporter platforms to be beamed down to a nearby planet.

While novices orienteer, experts teleport. Akin to being teleported to a precise but distant location, users with high domain and technical expertise like Angela Baer tend to jump directly to their final destination.

h4. Longer queries

Experts enter longer, more specific queries than novices. Domain experts like William Hayes often rely on their vocabulary of specific terminology, while technical experts such as Fane Tomescu are more likely than novices to use formatting techniques such as quotation marks in their queries (87% of experts compared with 47% of novices according to a 2000 study [1]).

h4. Fewer queries

Experts usually amend their queries less often than novices and move forward with a higher degree of confidence.

h4. More Documents Examined

Experts tend to review more documents and follow a greater number of links within those documents. Domain experts are especially adept at quickly determining whether or not a given document is useful.

In essence, experts often construct queries using numerous highly specific words which act to teleport [6] them directly to a destination, cutting out the query reformulation often practiced by novices. After having arrived at a destination, experts are then likely to explore the surrounding territory.

h2. Design considerations for Experts

Designing for experts involves facilitating their teleporting behaviour, helping them get to their destination as quickly as possible.

h4. Advanced syntax

Technical experts like Fane are often willing to learn special commands in exchange for having greater control. Commonly supported operators include AND, OR, and quotes for searching for exact phrases.

Image 8: Wolfram Alpha is designed to understand domain-specific terminology and return computed answers.

h4. Keyboard shortcuts

Keyboard shortcuts can also increase the speed of interaction. Google, for instance, allows users to press the up/down arrow keys on the keyboard to traverse results, and press return to go to the URL of the selected result.

Image 9: Google places a caret beside the currently-selected result.

h4. Filtering & sorting

Experts are more likely to engage with advanced sort and filtering controls than novices, including operations such as selecting ranges, filtering by format, or excluding certain terms (e.g. everything that includes “apples” but does not mention “oranges”).

Image 10: Getty Image’s Moodstream lets users search for stock photos using sliders.

h4. As-you-type results

As-you-type completion interfaces most often display query suggestions to users. However, another use case is to present actual results in the autocompletion interface, enabling users to skip the search results screen altogether and go directly to a specific document.

Image 11: Rather than suggesting terms to search for, Nutshell returns search results directly without needing to go to a separate page.

h4. Result table of contents

Providing links to the top destinations within a result can reduce the number of steps required for the expert to reach his destination.

Image 12: Google sometimes provides links to the top-level pages within a given site.

h2. Yin and Yang

While novices and experts practice two very different approaches to information seeking, it’s important not to overemphasis one at the expense of the other. As illustrated by the ancient Chinese symbol, understanding the behaviour of both novices and experts can help us design more informed, balanced search experiences.

The author would like to thank Cennydd Bowles for organising the UK writer’s retreat during which this article was written, as well as for the editorial guidance that he provided.

h4. References

[1] Vicki L. O’Day and Robin Jeffries; “Orienteering in an Information Landscape”:http://www.hpl.hp.com/techreports/92/HPL-92-127.pdf

[2] Christoph Hölscher & Gerhard Strube; “Web Search Behavior of Internet Experts and Newbies”:http://www9.org/w9cdrom/81/81.html

[3] Marti A Hearst; “Search User Interfaces”:http://searchuserinterfaces.com/book/sui_ch3_models_of_information_seeking.html#section_3.5

[4] Morten Hertzum and Erik Frokjaer; “Browsing and Querying in Online Documentation”:http://www.cparity.com/projects/AcmClassification/samples/230570.pdf

[5] Christopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, “Introduction to Information Retrieval”:http://www.cambridge.org/us/knowledge/location/?site_locale=en_US , Cambridge University Press. 2008.

[6] Jaime Teevan, Christine Alvarado, Mark S. Ackerman and David R. Karger; “The Perfect Search Engine is Not Enough”:http://people.csail.mit.edu/teevan/work/publications/papers/chi04.pdf

Storyboarding iPad Transitions

Greg Nudelman — Wed, 05 Jan 2011 09:05:23 GMT

If your clients are not yet asking you to design transitions, they will likely do that on your next project. Transitions are hot, and not just because they entertain the eye. In confined mobile computing interfaces, on tablet devices or in complex virtual environments, transitions are an authentic, minimalist way of enabling way-finding, displaying system state and exposing crucial functionality – in short, they are key in creating a superior user experience.

Transitions as design elements

Since the 1980s, designers have been drawing wireframes to represent web pages and device interfaces.¹ In the beginning, wireframes were static schematics that showed a single state of the page. With the emergence of dHTML in the 1990s, it became necessary to draw different states of specific dynamic page elements, so the designers adapted the wireframe methodology to document the beginning and end states of the dynamic elements. Still, designers and engineers had little or no control over what happened in between the beginning and end states—the browser or the operating system handled all transitions.

More recently, sophisticated mobile touch frameworks like iPhone, Android, Palm and Windows Mobile allowed unprecedented control over the speed and structure of the transitions, giving designers more tools with which to create a better experience in a confined mobile space.² Simultaneously, on the web, dynamic platforms like Flash and Flex gained tremendous ground, making it possible for designers to think about and document transitions because those were now part of the customer experience.

With the release of the Apple iPad, the Age of Transition has come to its full potential. On the iPad, Apple takes full advantage of some of the principles and ideas the company previously explored and perfected using the iPhone. On the bigger iPad screen, transitions achieve a new level of detail and sophistication, making the device come alive, and become a powerful, integral part of the experience.

Transitions Require Thinking Differently

As Jonathan Follett writes in his article “Interfaces That Flow: Transitions as Design Elements”:http://www.uxmatters.com/mt/archives/2007/04/interfaces-that-flow-transitions-as-design-elements.php, ³ many UX designers approach projects from a combination of information architecture and interaction design. These disciplines involve thinking that is quite different from constructing the continuous linear narratives required to design and document transitions. Nevertheless, by borrowing freely from the lessons of early animators, it is quite possible to adopt the existing wireframes methodology to convey the structure and rhythm of a user interface transition.

The task consists of wireframing each of the important changes (or “key frames”) that occur during the transition and stringing a bunch of wireframes together in a storyboard. By documenting the key aspects of the transition, it is possible to share them with the larger team and try out different transitions designs. Documenting the transitions also allows us to step back and consider them in a larger context of a specific use case or overall goal of progressive engagement and immersion.

Understanding iPad Transitions

In order to be able to design and document transitions using storyboards, we have to first understand design principles that designers of transitions use to convey the desired meaning. Let’s take a look at the Apple, Inc. video in Figure 1 showing selected transitions from what is arguably the most popular iPad application today: iTunes. Although many different transitions are shown in the video, we will be specifically looking at the two of them: “opening the iTunes application” (0:17-0:20 min) and “opening album details” (0:30 -0:36 min).

Figure 1: Video of iTunes transitions on the iPad [“View larger version on YouTube”:http://www.youtube.com/watch?v=Z03PR_4Ln90]

Borrowing from Chet and Guy’s excellent Devoxx presentation “Animation Rules!”:http://www.parleys.com/#st=5&sl=1&id=1578,⁴ we can identify seven key principles that specifically apply to the animated transitions on the iPad: # Component Relationship (background-foreground) # Illusion (motion perception and perceptual constancy) # Exaggeration (highlighting states, actions, and changes in state) # Staging (camera view, lighting, focus) # Acceleration and Deceleration (slow in and out) # Metaphors (using real-world analogies to convey complex digital events) # Simplicity (avoiding noise)

To understand how the seven principles above apply combine to make the transition work its magic, let’s do a step-by-step breakdown of the “opening the iTunes application” transition, shown in Figure 2.

Figure 2: Opening iTunes Application Step-by-Step

Using our seven key principles:

Component Relationship (background-foreground)
 This transition is essentially the process by which the iTunes application comes into the foreground, while the rest of the apps recede into the background. In the first row, the transition starts out with the home screen and apps icons firmly in the foreground. By the end of the row, we can see that the home screen recedes and darkens, while the iTunes app (represented by a white square) slowly comes into the foreground. By the second row, the background-foreground transition is essentially complete – we can see only the loading iTunes app against the black background.

Illusion (motion perception and perceptual constancy) 
This transition creates its magic via an illusion of “flying into” the device, and eventually meeting the white square that represents the iTunes app. To accomplish this, the animation shows us “flying” through the layer of the apps icons on the home screen. The other app icons begin to “fly” to the sides of the screen in a circular pattern, as shown in row 1. The most interesting part of the illusion is the kind of “bait-and-switch”. If you look carefully, you’ll see that the app icons never make it off screen. Just before we “pass through the icons layer” and “witness” the icons “flying off screen”, the background goes completely black, and our attention is focused on the white rectangle. The illusion is complete.

Exaggeration (highlighting states, actions, and changes in state)
In this transition, the lighting effects are used to exaggerate the switch between the background and foreground. In the second row, the background goes completely black, to highlight the change in state. Exaggeration can also be used to warp the shape of an object to emphasize movement, as in is used more in the “genie” effects and transitions.

Staging (camera view, lighting, focus) 
Subtle but powerful lighting is used throughout the transition as the primary means for focusing our attention on the foreground of the opening window of the iTunes app through subtle darkening of the background (principle 1). Lighting is also used to accomplish the bait-and-switch in the Illusion principle.

Acceleration and Deceleration (slow in and out)
 Our brains know from experience that objects do not start running at top speed or “stop on the dime”. To make the movement more life-like, the animation accelerates into the movement very slowly, picking up pace in later screenshots, as evidenced by the increasing “smudginess” of the icons in the first row. Not surprisingly, the bait-and-switch happens in the fastest moment of the transition to pull of the illusion that the homepage icons actually “fly off screen”. The transition then slows down again in the last row to smoothly fade in the iTunes content elements, deliberately giving the auxiliary page elements and pictures time to “catch up” and making the page load appear smoother.

Metaphors (using real-world analogies to convey complex digital events)
 The most effective transitions use real-life elements to provide a frame of reference which makes the animation more realistic. In this case, the icons on the home screen are moving to the sides, creating an overall illusion of moving through space, or deeper “into” the device itself to convey a digital event of opening an application inside the device.

Simplicity (avoiding noise)
The overriding theme of this transition is its apparent simplicity. During the transition, iTunes is not doing anything particularly complicated or earth-shattering. The magic comes not from one particular element, but through carefully blending and combining the lighting and movement to create a smooth cohesive digital dance, perfectly orchestrated from beginning to the end.

Storyboarding iPad Transitions

The key to successfully designing and storyboarding the transitions is understanding and applying the seven animation principles we discussed above. To demonstrate how this can be done, let’s use a slightly more complex transition: the iTunes “opening album details”, shown in Figure 3.

Figure 3: Opening iTunes Album Details Step-by-Step

Here again, we see the seven principles at work:

Component Relationship (background-foreground)
 This entire transition can be viewed as bringing the selected album cover into the foreground, while the rest of the iTunes application recedes slightly into the background.

Illusion (motion perception and perceptual constancy) 
The animation shows us the illusion of the album flying forward on the screen while flipping 180 degrees. The most interesting part of the illusion is the switch from darker gray “back” of the album to a while loading screen (midway through the second row). This sleigh of hand changes the focus to the white cover to make the transition believable.

Exaggeration (highlighting states, actions, and changes in state)
 In this transition again, the lighting effects are used to exaggerate the switch between the background and foreground. Midway through the second row the album turns completely white against the slightly darker background.

Staging (camera view, lighting, focus) 
In the beginning the iTunes application darkens gradually, and reaches its full saturation about half-way through the second row to create the background against which the album will be staged. The album, on the other hand, switches first from color to darker gray, then to solid white to jump to the foreground.

Acceleration and Deceleration (slow in and out)
 The animation starts slowly, and achieves top speed half-way through the second row to quickly switch from the dark gray flipping rectangle to a solid white loading page. Just as in the previously discussed “opening iTunes” transition, this transition also slows down in the last row to smoothly fade in the iTunes album cover content elements.

Metaphors (using real-world analogies to convey complex digital events) 
This transition invokes the magical feeling of opening picking the old LP album off the shelf and flipping it over to see the back cover by creating the illusion of the album jumping off the page and flipping 180 degrees horizontally around the middle.

Simplicity (avoiding noise) 
While a bit more complex than the “opening iTunes application”, this transition can nevertheless be adequately described by looking at only 12 screenshots.

Once the transition design principles are understood, the process of drawing the storyboard becomes fairly straightforward. I use the same method that Galileo Galilei used four centuries ago when he first diagrammed the step-by-step movement of the sun spots in 1613.⁵ The basic transition storyboard for the “Opening iTunes Details” transition is shown in Figure 4.

Figure 4: Storyboarding iPad Transitions Using Post-it Notes [“See larger version”:/files/banda/storyboarding-ipad/figure4_ipadtransitions_postitnotes_large.png]

Now Start Making Your Own Transitions

As you try your own hand in transition storyboarding, here are a few points to keep in mind:

Use appropriate materials 

To diagram transitions, I prefer to use medium-size post-it notes that measure 3-inch square. I draw each of the steps in the transition using a soft retractable pencil with a good eraser. This allows me to quickly diagram portrait and landscape transitions, and everything in between. Because the iPad is a rectangle, not a square, I leave the extra space left on the right of the post-it note (on the bottom for landscape) to write the additional explanation for each step or simply leave it blank.

Simplify shading 

As I said above, on the iPad the lighting is foundation to expressing Component Relationship, Exaggeration, and Staging principles, so it makes sense to take a disciplined approach to drawing various shades of light and dark in your storyboard. I find that the easiest approach is to draw shading on top of the picture as light lines at a 45 degree angle. As you can see in the last three post-its, I use tighter line spacing to indicate progressively darker shading.

Get the basics down first 

When I first approach the transition design, I make only the post-its necessary to convey the overall movement of the various elements and basic component relationship. I sketch quickly using very rough strokes, and use a ruler and templates whenever possible to make my job easier.

Stick to 6-8 post-its

 As you can see in Figure 4, it is not necessary to draw all 12 original key frames we saw in figure 3. To convey the basic structure of a transition, I typically try to use only 6-8 post-it notes. Using fewer steps keeps me focused on the principle of simplicity: if it takes me more than 8 post-it notes to describe the transition, it is probably too complex and I immediately look for unnecessary elements or animation that needs to be eliminated or scaled back.

Ignore Acceleration and Deceleration 

Above we spoke at length about the Acceleration and Deceleration principle. This idea is essential to creating effective, believable transitions. However, when drawing a rough storyboard of 6-8 post-its, this is the one principle that I found can be safely ignored. Once people understand this principle, most folks can extrapolate from your rough drawings to imagine the complete smooth transition “in their mind’s eye”. As long as you make it clear to your team that this is only a rough storyboard that the end result will in fact follow the principle, you can safely ignore the subject and concentrate on the relationship, movement and shading of screen elements.

Draw the complete story

 Transitions do not happen in isolation – they are an integral part of the overall customer experience. Thus, when I storyboard transitions, I typically do it in the context of the entire use case. This helps me make sure that the particular transition makes sense in the complete context and in combination with other transitions. For example, when I use the “flip” transition to show the search results on the map, and then use the “slide back” transition to go back to the list of search results, the storyboard will quickly reveal the inconsistency in the mental model of the interface I am trying to create and the problem transition will feel awkward when walking through the use entire storyboard.

Sketch a few different transition designs 

When I approach a given transition, I usually try out 3-4 different design approaches to see which transition creates the effect I am seeking. Sometimes I find that I need to create 10 or more sets of ideas for more complex and critical interactions. The point of this initial sketching is not to create the complete and final blueprint, but to help you visualize how a given transition design option would feel with the rest of the app interactions. Doing the transition with post-it notes allows me to quickly add a new transition or re-position the existing post-its to create and try out several different scenarios, often while engaging in the active team discussion. I recommend you make copies or take photos of your boards periodically to preserve promising design directions before repositioning the post-it notes and changing the transition layout again.

Obtain Initial Stakeholder Approval

 In addition to helping you find the best design approach, a rough storyboard is also a fantastic tool for conveying various design options to your team for joint discussion and brainstorming as well as for obtaining initial stakeholder buy-in. It’s a lot easier to discuss the merits of a particular transition movement and information architecture when everyone is quite literally on the same page looking at your complete use case storyboard.

Creating the Final Transition Blueprint

When you obtain the initial stakeholder approval using your rough storyboard drawing, you will need to document the final storyboard design that the engineers to actually create. Here you have a couple of options.

One approach is to use Flash to create the transition with the final high-fidelity look and feel. This is certainly a valid option. However, I found Flash to be more useful for higher-fidelity usability testing and final stakeholder approval than for describing transitions to engineers. Here is why: most developers do not read Flash code and most transitions are simply too fast for the eye to understand in detail the subtleties of acceleration and shading simply by looking at a running a Flash file. I have had several instances of getting not exactly what I specified or else getting something completely different, only to have the engineers claim that “this is exactly what the Flash looked like”. This is especially a big problem with distributed multi-lingual teams where communication is an issue.

The method that I found to work well is to specify (e.g. create a wireframe for) each of the frames at regular intervals of every 50-100 milliseconds for the entire duration of the transition. Most transitions are between 0.5 – 1.2 seconds, so you will need to create anywhere between 5-24 wireframes in your favorite wireframing tool such as Fireworks, OmniGraffle or Visio. Stringing these frames together in document pages will create a short movie that will comprise the complete blueprint that will describe the position, shading, and movement of each element that will communicate clearly and exactly so the engineers can create the exact transition you envisioned.

While this seems at first like a lot of work, after a bit of practice the wireframing goes fairly quickly, as the difference between the each new page and the one before it is only a slight change in position and shading. As long as we firmly keep in mind the principles by which iPad transitions work, we can easily diagram relevant steps for rich, expressive transitions.

To continue this conversation, add a comment below or reach out to Greg at ”@designcaffeine”:http://twitter.com/designcaffeine or through his website, “DesignCaffeine.com”:http://www.DesignCaffeine.com.

Interested in more UX sketching techniques? Join us Saturday, May 28th, 2011 at UX SketchCamp [“SketchCamp.com”:http://www.sketchcamp.com or ”@sketchcamp”:http://twitter.com/sketchcamp on Twitter] in San Francisco for a chance to learn from the experts, practice UX sketching and share what you know with others.

References

1. “Wireframing Marathon Starts”:http://ciohappyhour.com/wireframing-marathon-starts/; CIO Happy Hour, September 2010

2. See my article “Designing Mobile Search: Turning Limitations into Opportunities”:http://www.uxmatters.com/mt/archives/2010/03/designing-mobile-search-turning-limitations-into-opportunities.php; UX Matters, March 2010.

3. Jonathan Follett; “Interfaces That Flow: Transitions as Design Elements”:http://www.uxmatters.com/mt/archives/2007/04/interfaces-that-flow-transitions-as-design-elements.php; UX Matters, July 2007

4. Chet Haase and Romain Guy; “Animation Rules!”:http://www.parleys.com/#st=5&sl=1&id=1578; Devoxx ‘09

5. Galileo documented the movement of the sun spots in his triumphant “Istoria e Dimostrazioni Intorno Alle Macchie Solari e Loro Accidenti Rome”:http://physics.ship.edu/~mrc/pfs/110/inside_out/vu1/Galileo/Things/g_sunspots.html (History and Demonstrations Concerning Sunspots and their Properties); 1613.

The Stranger's Long Neck

Jeff Parks — Mon, 27 Sep 2010 16:19:57 GMT

Show Time: 33 minutes 42 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

Ireland’s Gerry McGovern shares a few of the key ideas in his recent publication The Stranger’s Long Neck – How to Deliver What Your Customers Really Want. Mr. McGovern, who will be teaching a Masterclass series in Canada on the importance of task management this November, discusses several of the key findings in his new book, including:

Trading with strangers

- The customer is a stranger. On the Web, the customer isn’t king—they’re dictator. When they come to your website, they have a small set of tasks (long neck) that really matter to them. If they can’t complete these top tasks quickly, they leave.
- There is an existential challenge going on right now between organization-centric and customer-centric thinking. Customer-centric thinking is winning.

From Long Tail to Dead Zone

- The Long Tail theory says that the Web allows you to sell more of less, that we are seeing the decline of the blockbuster and the rise of the niche.
- The Long Tail is often a Dead Zone of extremely low demand and hard to find, poor quality products.

The rise of the Long Neck

- The Web is exploding with quantity but quality is still relatively finite. Quality is the ‘long neck’; the small set of stuff that really matters to the customer.
- Understanding and managing the long neck has never been more important.
- Remember that the customer’s long neck—what really matters to the customer—is rarely the organization’s long neck —what really matters to the organization.

A secret method for understanding your customers

- A unique voting method that identifies your customers’ long neck.
- Developed over 10 years, with over 50,000 customers voting in multiple languages and countries.
- Used by the BBC, Tetra Pak, IKEA, Schlumberger, Wells Fargo, Microsoft, Cisco, OECD, Vanguard, Rolls-Royce, US Internal Revenue Service, etc.

Organization thinking versus customer thinking

- Case study that shows how car company managers think differently about how customers buy cars to how customers themselves think.
- Explanation of how to frame the task identification question.

Deliver what customers want—not what you want

- Case study of Microsoft Pinpoint, a website to help businesses find approved Microsoft IT vendors and consultants.
- What’s the top task of US small and medium businesses when it comes to IT? Security.

Measuring success: Back to basics

- Why traditional web metrics such as page views, number of visitors, etc., are often misleading
- Observation-based technique to measure online behaviour.
- The key metrics of task measurement: completion rate, disaster rate, completion time

Carrying out a task measurement

- The benefits of remote measurement
- How to run an actual measurement session

This podcast has been sponsored by:

iTunes Del.icio.us Boxes and Arrows Podcast theme music generously provided by Bumper Tunes

Publishers of world class content for students, researchers, and practitioners in the UX and HCI fields. To learn more visit http://www.mkp.com/hci

From concepts to rich prototypes and detailed specifications, all in one tool. Get your free 30-day trial at www.axure.com

Boxes & Arrows: Since 2001, Boxes & Arrows has been a peer-written journal promoting contributors who want to provoke thinking, push limits, and teach a few things along the way.

Contribute as an editor or author, and get your ideas out there. boxesandarrows.com/about/participate

So You Wanna Build a Library, Eh?

Nathan Curtis — Mon, 13 Sep 2010 22:19:32 GMT

The following article is an abridged version of Chapter 7 of Nathan Curtis’s 2009 book, Modular Web Design published by New Riders. The book’s first half addresses how to modularly break down your design, build it back up, and communicate in new and interesting ways. With those design techniques in hand, the book then drills into how to organize and build a library, teach it to others, and establish a process for maintaining it for an organization.

Design patterns and modular components are effective techniques for designing and building long-lasting, consistent experiences. You may reach the point where you ask yourself “Is it time to build a library for our team?”

Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial. It takes time and effort to get off the ground, can trigger significant and uncomfortable organizational change, and comes with an ongoing maintenance cost. In some cases, libraries are not the answer and yes, sometimes libraries fail. Nobody wants to invest the time, effort, and personal capital only to have nothing to show for it.

Therefore, precede any kind of library build out with a period of discernment. Before you dive, ask yourself and your teammates the following eight questions to gauge whether a library is right for you.

1. Why Do You Want Create a Library?

What is your primary rationale for building a library? What motivates you?
At the top of nearly everyone’s list is usually one of two benefits: efficiency or consistency. Some value speed through reuse: get design done faster, be more productive, save time, save money! Others see opportunities for governance and consistency, using the library as a baseline to sustain a design system over time.

“ Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial. ”

Beyond efficiency and consistency, other benefits that drive teams include:

Memory: A destination to record and refer to all the design decisions made in creating a large-scale experience.

Portability: Designers come and go. Project priorities change. A library should make you more nimble in shifting resourcing and focus.

Vocabulary: Establish and promote common understanding that includes terms you use for items, page types, and even deliverables.

Authority: Provide a more credible resource on which to make design decisions, prioritize efforts, and easily refer to conventions.

Predictability: Have a foundation to discuss and more closely approximate the impact of a design decision.

Collaboration: Amp up collaboration in your organization to trigger conversations, share knowledge, and learn together.

2. Are You Building the Right Kind of Library?

When it comes to libraries, teams usually find themselves choosing between a library of patterns or components.

A design pattern is a solution to a recurring problem. Patterns offer principles to follow and avoid specifics like style, editorial guidelines, page location, and finalized code. Libraries of design patterns are ideal for teams that design many experiences, such as Yahoo’s team that designs products with unique visual systems that adhere to a larger, common brand.

A component is a chunk of a page design. Experiences can reuse components for navigation (such as header, footer, and local nav), content (such as video players and page titles), and more. A component library is ideal for organizations that have built a system of modular HTML and CSS, and these teams can complement the code library with a collection of reusable design assets for wireframes or comps.

Choosing between patterns and components may not be an either / or question. In fact, one team built libraries for both patterns (for example, Tabs) as well as components (for example, tabbed product details, tabbed content module, tabbed search results, and so on). Other teams have hedged their bets by embedding aspects of one approach into the guidelines and spirit of the other, most commonly via pattern-like guidelines incorporated into the more specific component definitions.

Consider a pattern library if your team has:

Many design systems that are intentionally different or will not be reconciled into a single component library.
Capability to document patterns more specific than public libraries like Yahoo Design Patterns, welie.com, and ui-patterns.com.
Known opposition to prescriptive approaches, but a willingness to use common guidelines.

Consider a component library if your team has:

A specific visual design system, including grid(s), layout, color palettes and typography.
Many reusable components (page “chunks”) within that system.
Diverse groups across an organization that must work together using that system.
Interest in and capability of sustaining that design and code system across groups, projects and time.
Strong, centralized influence to create, deploy, and maintain a library (or plans to centralize influence via a library).

“ A comprehensive library of design standards doesn’t end with design patterns and modular components. A team could consider … include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more. ”

Finally, a comprehensive library of design standards doesn’t end with design patterns and modular components. Instead, a team could consider expanding their repertoire to include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

3. Is Your Experience Ready for a Library?

Ok, so you’ve got dreams of efficiencies, consistency, standards, and more. However, just because you’ve built a website, that doesn’t automatically imply that you should build a library. In fact, there are plenty of websites for which a library won’t net any benefit. You should take a long, hard look at your design system to ensure it warrants a library.

Scale: Libraries can be invaluable to large, distributed teams supporting many products or a site with thousands – or millions – of pages. On the other hand, if you are a small and tight-knit team constantly communicating across cube walls, then there’s no need to codify standards. Heck, there’s no need to document anything at all – just get real and build stuff.

Relevance: Rarely do experiences of any scale contain no reusable elements. However, some site areas – like an e-commerce checkout or an account management portal – may be unique, built once, and not duplicated again short of a redesign. Why standardize something that’s never reused?

Stability: Be careful not to standardize an experience too soon. A design system should stabilize before you invest in codifying layouts, grids, typography, patterns, and components.

Disparity: Instead of one simple set of grids, styles, and reusable chunks, you may have multiple, distinct design systems. Do you merge them into one library? If now, is it worth it to create distinct and potentially overlapping libraries?

4. Is Someone Ready to be a Librarian?

“ Just because you’ve built a website, that doesn’t automatically imply that you should build a library. ”

Building and sustaining a component library takes an evangelizing advocate. That person may be you, or someone you manage or work with. Almost always, the librarian wears many hats:

Leader: You’ll promote a new way of thinking, shepherding participants into common practice and evangelizing the techniques, benefits, and spirit of the library.

Target: You’ll be a lightning rod for the library, and even the cause of controversy in a design organization. Others may point to you as the standards police that constrains them from being creative.

Writer: You’ll be an author, or at least a contributor and reviewer of other’s contributions, for items like guidelines, library cheat sheets, and blog posts.

Teacher: You’ll teach principles and basic fundamentals about what’s where and how to use it. Help requests can be disruptive, and you’ll have to be patient, determined, and flexible.

5. Is Your Design Team Ready for a Library?

A library can transform how a team operates. Gone are the days where every project is a blank canvas where a designer creates a creative and original work of art. Instead, designers are equipped with helpful starting points as a framework in which to operate. Those constraints can be simultaneously welcome and controversial.

Above all, your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel. Templates with grids, libraries, styles, and pre-made page chunks don’t turn designers into robotic automatons. But designers often react that way. You’ll have to convince designers that library starting points can focus creativity.

Other team attributes that influence library readiness include:

Size: How big is your design team? The larger the team, the more likely techniques, styles and deliverables vary. Libraries and templates can get your team synched up and communicating more consistently.

Overlap: How much do designs contain overlapping patterns and components? If your team is designing towards a common experience, a library can be a key part of a holistic strategy.

Distribution: Is your team spread out geographically? Standard design assets can mitigate impacts of reduced face-to-face collaboration.

Adaptability: Will your team be able to adapt to design practices that involve a library?

Stability: How stable is your team? Do designers come and go often? Learning library details is an investment with a return that increases the longer each designer uses it.

Advocacy: Do you have team members that are jazzed about or knowledgeable of reuse? Are they willing to be partners or champions?

6. Is Your Organization Ready for a Library?

“ Your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel. ”

You’ll need to have a pitch that explains the library in simple and concrete terms. What is it? How does it work? What does it mean to me? These questions hint at the profound impacts a library can have:

Workflow: Design libraries impact at least two critical workflows: how you produce a solution for each project and how you maintain assets, guidelines, and documentation across projects.

Collaboration: Do key team members – such as engineers and designers – have a common foundation to communicate on?

Documentation: You got to make it easy for people to refer to, find, learn, and integrate reusable assets into their own practices, whether via a component ID annotation on a wireframe, a PDF’s link to online documentation, or consistent HTML comments in your code.

Timing: When change is in the air, there may be opportunity to insert a library into the discussion and approach. Can you time the expansion of your library to dovetail with when your experience are already undergoing significant change?

7. Is Management Ready to Support a Library?

None of your planning and efforts will matter if you lack management support. They must vocalize a public belief in your effort as well as pony up time, money, and resources. It’s your duty to communicate a plan – and the return on that investment – to sell your management on why a library matters.

Unfortunately, even when the library is otherwise a good idea, management support sometimes wavers in instances like:

Lack of Priority: It can happen to the best of teams. You get your top talent together, you start roughing out a framework, and then projects hit. You get distracted. It’s up to management to carve out sufficient time for you, or else the library becomes stale and ineffective.

Insufficient Hardware and Software: It’s up to managers to ensure that designers have the right hardware and software installed so they can use the design assets. My confusion turned into empathy when I sat at a designer’s desk and watched for TEN MINUTES as the software tool launched on his out-of-date laptop. My query of “This is unacceptable. Haven’t you asked for an update?” was met with “You can only ask so many times” and a shrug.

Leadership and Evangelism: Ensure management is on message. Prep them with simple ways to communicate library value and help them avoid undermining you with explanations like “the library is another good idea, but if it doesn’t work for you, shouldn’t disrupt your own personal approach if you feel your way is more effective.”

Background Support: Public declarations are important, but so are the back-channel efforts. Your managers need to open doors to connect you with key players and partners. Knowing what doors to open is a two-way street, so help your managers understand the obstacles and why you need help.

8. So, Are You Really Ready to Build a Library?

“ Take a deep breath, because you’ve got a fun ride ahead. ”

So, your design system is stable, you’ve got some champions backing you up, and you know just what your organization needs. You are ready to put yourself on the line. You believe.

Then take a deep breath, because you’ve got a fun ride ahead.

Diagram of How to Create a UX Design Library (PDF)

Up next, you’ll want craft a plan and read all you can from all the best authors and online resources. You then discover, organize, and prioritize what goes in your library. You’ll setup a platform for managing your catalog and publishing your standards. You may even equip one or more software tools with a library of reusable assets so that your team can create better design and deliverables, faster.

It’s time to build a library.

Boxes and Arrows

Leaping Into Indie UX

Podcast Summary

Quotes

Thanks!

Driving Holism in Cross-channel Projects

Podcast Summary

Quotes

Notes

The Past and Future of Boxes and Arrows

Podcast Summary

Pitch in on B&A

Thanks!

Das Design Revolution

1. First and foremost, context is nothing

2. Don’t pay too much attention to testing

3. You can never arrive at a solution too quickly

4. Content is not your job

5. Considerations of technology – somebody else’s job

6. Collaboration, not exactly a dirty word, but a bit icky

7. Accessibility works best as an afterthought

8. Photoshop: let that be where responsibility ends

9. Lorem ipsum dolor sit amet

10. Don’t throw your net too wide

The Story's the Thing

Leonardo's Kitchen Nightmare

Some of Leonardo’s projects failed because of their execution. The strange tale of Leonardo’s “Kitchen Nightmare” plays out like a Shakespearean “comedy of errors” where a visionary designer’s experiments all work perfectly to extremely disastrous results.

When Works As Designed Still Fails

Three Lessons for Designers

1. Do not be afraid to fail

2. Use positive judgement to explore the value and benefit of ideas

3. Do not underestimate the importance of execution

Conclusions

Footnotes

Integrating UX into the Product Backlog

Agile teams and UX problems

Integrating UX into the product backlog

Creating a UX Integration Matrix

Advantages to using the UXI Matrix

Groom the backlog

Reduce design overhead

Facilitate collaboration

Track user involvement and other UX metrics

Review UX metrics during sprint retrospectives

Improving your team’s design decisions

UX Integration Matrix template

Footnotes

Are Design Patterns an Anti-pattern?

The case against design patterns

Design patterns are not effective training tools.

Design patterns don’t replace UX expertise

Completeness and learn-ability are in conflict.

Design Patterns take a lot of investment.

Design Patterns should help non – UX people first

Why do people make design pattern libraries anyway?

What is the solution then?

Create a design ecosystem instead of documentation.

A code library beats a pattern library

How do you get such a library?

More on design patterns

Complexity and User Experience

The best products don’t focus on features, they focus on clarity. Problems should be fixed through simple solutions, something you don’t have to configure, maintain, control. The perfect solution needs to be so simple and transparent you forget it’s even there.

Why you should reduce complexity in scope

Properly defining scope

Preventing scope creep

Why you should reduce internal design complexity

Further Reading on Compexity and Scope

Managing internal design complexity

Conclusion

Alignment Diagrams

Mapping The Experience

Example 1: Service Blueprint

Example 2: Mental Model Diagram

Locating Value

Who Creates Alignment Diagrams?

1. Conducting Research

2. Synthesizing Findings

3. Visualizing Information

4. Brainstorming

5. Prototyping Solutions

Use appropriate materials 

Simplify shading 

Get the basics down first 

Ignore Acceleration and Deceleration 

Sketch a few different transition designs 