Hagan Rivers is a walking encyclopedia of web app design knowledge. A frequent speaker at our events, she has an amazing knack for making the highly complex digestible and easy to understand. Examining the structure of your application can reveal the places where your users struggle and provide you with opportunities.

In today’s UIEtips, we’re reprinting an interview that I had with Hagan about web application design. It was a fun discussion, talking about how she’s come up with the concepts, such as hubs, interviews, and her technique for diagramming the structure of web apps.

Read the article, Discovering Web App Structure: A Discussion with Hagan Rivers.

Hagan will also be bringing her expertise to an upcoming UIE Virtual Seminar, Designing Dashboards: The Do’s, Don’ts, and D’ohs!. She’ll show you a bunch of dashboards. And she’ll give you tips for helping stakeholders understand the implementation benefits and drawbacks of seemingly simple components, from graphs to customizable panels. You won’t want to miss it!

The world of mobile design is new, and therefore, scary for many. The comforts of designing for the desktop disappear when we have to deal with these portable, tiny devices. Even the way we design – the processes and techniques we’ve honed over many years of practice – suddenly doesn’t work the same. We need to think about our work in new ways. Very scary.

Yet this scary new world also brings tremendous opportunity. Thanks to the pioneers in this space, there’s a new appreciation for the value of design. That new appreciation gives us room to rejigger the broken parts of how we’ve designed in the past. And that’s really exciting.

In this week’s UIEtips, I explore both the scary and the exciting that comes with mobile design. Join me as I look at four areas where designers will face challenges and opportunities in the coming year.

Read the article: UX & Mobile Design – 2012′s Challenges and Opportunities.

If you’re facing these mobile design challenges and opportunities, then you’re in for a real treat. We’ve just announced our new spring conference: UX Immersion 2012, which has a focus on creating great mobile designs. You’ll want to consider one or two of the in-depth, full-day workshops by Rachel Hinman, Luke Wroblewski, or James Robertson. These folks will help you overcome the challenges and take advantage of the opportunities. See the entire UX Immersion program.

How are you dealing with the challenges of mobile design? How have you taken advantage of the opportunities? Leave your thoughts below.

You’re about to see a project we’ve been working on for several months. A brand new conference bringing the newest, most critical thinking around two separate and important topics: mobile design and Agile development.

These experts will dive deep and get to the nitty-gritty details that will make you a stronger and more valuable UX Pro.

Agile Process

• Hugh Beyer – UX Design Inside Agile Development
• Jeff Gothelf – Lean UX: A Radical Approach to Integrating Design into Agile
• Dave McFarland – Demystifying jQuery for Agile Prototyping

Mobile Design

• Rachel Hinman – Creating Great Mobile User Experiences
• Luke Wroblewski – A Detailed Look at Designing Mobile Inputs
• James Robertson – Innovative Mobile Intranet Designs for Your Enterprise

Get First Dibs on a Seat When You Become a VIP

There are only 100 specially priced $1,349 spots available for the 3-day UX Immersion Conference. One of them can be yours.

VIPs will receive a special link to access registration on Monday, January 30. Everyone else will have to wait until Tuesday night to save their spot.

So be sure to get on the VIP list and start exploring the UX Immersion Conference.

Users’ behaviors change based on how they view digital content. The desktop computer is no longer the norm for reading content and conducting web interactions. As a designer you must think about designing for the plethora of mobile devices now available. It’s not a question of whether to consider mobile design, it’s a matter of actually planning and implementing it now.

And how we communicate our designs is shifting. Agile threw a wrench into wireframes and the solid set of deliverables that would serve as a contract. More and more, design teams are testing out the idea of a collaborative journey where design and development are working together in short sprints.

However, one major core UX principle has not changed: put the user first, think about who they are and what they need, and build to their tasks.

3 Intense Days to Make You a Stronger UX Pro

We thought about all of this when we were putting together the UX Immersion Conference 2012 – Agile/Mobile happening in Portland, OR, April 23-25, 2012. Our vision for this event is to bring the newest, most critical thinking around two separate and important topics: mobile design and the Agile process. We’re not presenting brief introductions and sending everyone on their way. We want UX pros to get an in-depth understanding of what’s new and what’s changing.

We’ve carefully designed the UX Immersion program to get you completely up to speed on where we are in these new worlds. You’ll learn the latest techniques for dealing with a UX process in an Agile environment. You’ll discover what it takes to build usable, useful, and delightful mobile apps that work within the ever-changing standards.

We’ve assembled an amazing team of leading-edge thinkers on these new forces. These folks have been pioneering these areas. They are the thought-leaders that everyone goes to for the tough problems. And, importantly, they are excellent teachers who can make a day of this material really fun and engaging. Who are they? You’ll find out really soon.

Get on the VIP List

Later this week, the UX Immersion 2012 – Agile/Mobile web site will launch. On January 30, registration will open exclusively to those on the VIP list (believe me, you want to be be on the VIP list). These folks will get the first shot at the 100 seats available at the lowest conference price. Starting at 5:00 pm, January 31, we open registration to everyone.

Become a VIP by signing up for the UX Immersion email list. As a VIP you’re guaranteed the lowest conference price, a conference gift, and other special perks. You can also follow us on Twitter for the latest conference updates and news.

We’ll see you in Portland in April.

In many ways, data visualization will take a message and make it more succinct. A good visualization can simplify the most complicated data, and often provide an interactive component with the user that a string of words can’t accomplish. The right data visualization will save the user time and provide a better experience.

In today’s UIEtips, Noah Iliinsky explores what makes data visualization so interesting. You might be surprised that biology has something to do with it.

Read the article, Why Visualization.

If you’re looking to tell a story through visualization, you’ll want to join us for Noah’s upcoming UIE Virtual Seminar on Thursday, February 2. Noah will show you how to choose an appropriate story for visualization then how to tell it. Learn more about his seminar.

The latest of the obviously obvious findings we’ve come up with? That teams who don’t have a shared understanding of their design rarely succeed at producing a great product. See? It’s obvious.

Yet it surprises me that quite frequently the obvious is not what people do. Many teams that we’ve studied don’t pay attention to whether they have a shared understanding or not. They don’t create a process to ensure everyone is on the same page. Then they wonder why their results aren’t what they want.

In today’s UIEtips, I describe the two types of shared understanding we uncovered and how one of them is far more likely to end with a successful design. I’m betting this is an article that will create some interesting discussions amongst your team.

Read the article: Attaining a Collaborative Shared Understanding.

A collaborative shared understanding is a key component of successful Agile projects. Fortunately, on January 24, Anders Ramsay will be sharing his techniques for helping teams collaborate in his UIE Virtual Seminar, Designing with Agile. Bring your team and learn the best techniques.

Have you transitioned from a contractual approach to a collaborative approach to attaining shared understanding? We’d love to hear how it went (or is going). Leave us a note below.

In the last installment, we talked about the distinction between Hands contractors and Brains consultants. Hands are brought in by the team as an extra resource to complete work the team already knows how to do. Brains are brought in by the team to provide expertise and insight on the best way to do something the team is struggling with.

Hands and Brains require completely different skills, have different approaches, and run into different challenges. Knowing which you want to be is important.

The Role of Hands

The UX professionals who make great Hands are passionate about producing stuff. Whether it’s a pile of wireframes or a boatload of usability test sessions, they can crank through them. More importantly, they tackle every single piece of the project joyfully and proudly.

The thing to remember is someone who signs up to be Hands typically doesn’t get to say how the project is done. The team decides that up front, often before the project is started. It’s up to the Hands to match the work exactly, making it impossible to know which elements came from the Hands and which came from other team members.

When it comes to how the work is done, creativity and previous experience aren’t playing big roles. In fact, they are frowned upon. While the team focuses on getting everything done by the end project, they don’t want to step back and take the time to rethink what they are doing.

The Hands will get management’s attention if they have tricks and techniques for speeding up production, while keeping the results indistinguishable from what’s been done so far. An experienced Hands contractor brings speed and agility, while playing the chameleon to match the work of their temporary teammates.

Bring in the Brains

This is a complete opposite to the Brains—who aren’t about production at all, but instead about strategy. The Brains, when at the top of their game, are the sheriffs, coming in to clean up the town. When a team is stuck and not making progress, and it feels like they’ve tried everything without results, they call in the Brains.

Unlike the Hands, the Brains doesn’t make a good producer. Their value is squandered if they spend the bulk of their project time churning out similar items. Of course, if the team is struggling with what to produce and how, the Brains can get them started, showing them the technique and coaching them through the work. But, in this scenario, the Brains quickly backs away, as soon as it’s clear the team members can produce their own results. (Some Brains will bring Hands into the project at this point, working jointly.)

Instead, the Brains’ real value is in strategic understanding of the situation. The Brains looks at the entire scope of the project, studies the goals, and assesses the team’s capabilities and flaws.

Then the Brains suggests a new plan. They get the team started on the plan. They train the team on the tricks and techniques that will get them through that plan. Then they leave town, just like the sheriff, to go off and clean up the next team’s mess.

Why The Difference Matters

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

The Brains aren’t challenged by production work. Once they’ve done one screen or conducted one test session, they’re ready to move on to something completely different. The Brains love the variety of the tasks—coming in to something new. The Brains love seeing problems and solutions nobody else seems to see. The Brains are energized when those problems are particularly gnarly and the solutions are deviously elegant.

The Hands struggle with strategy. They always feel they’re the wrong people to ask—that someone else should’ve figured this all out by now. They thrive on having a set of constraints, a schedule, and a near impossible pile of similar things to do. They love to crank through the work, seeing the Done Pile grow while watching the To Do Pile shrink. They don’t mind their work blending with the rest of the team’s—their contribution becoming invisible to anyone outside the team. They are energized by completion.

In other words, Hands thrive on walking into a project that’s well defined while the Brains thrive on walking into a project that’s poorly understood. That’s why it’s difficult to be both. It’s a very rare person who thrives on both definition and chaos. For everyone else, they need to choose one or the other.

I’ve seen managers who have tried to have one individual contributor play both the Hands and the Brains. Often this is because of resource constraints or not realizing there’s a difference. Unfortunately, this inevitably ends in disaster, because of the opposing strengths and weaknesses of Hands and Brains. Don’t fall into this trap.

What do you thrive on? What energizes you? Where do you get frustrated? Understanding this will help you figure out if you are suited for the Hands or if you ought to be the Brains.

Back December 2011, we asked your help in naming our brand new conference. There weren’t a lot of details other than it’s a 3-day consisting of full-day workshops and one day of short talks all focusing on two separate themes – mobile design and Agile. Like all the UIE events, we’re loading this conference with field-leading, edge-defining, top-caliber speakers providing you with techniques to immediately make a difference with your designs and inspiring insights.

We certainly weren’t disappointed with the response. We received over 450 entries.

Many of the suggestions consisted of creating a new word. Mogility, MoAgile, Magile, and Magility were popular entries.

Some folks went the acronym route. Magic: The Mobile – Agile Conference, MAID: Mobile Agile Insight & Design, MAX: Mobile Agile Experience, and MoMMA:Masters of Mobile Media and Agile.

All these submissions provided ammo for another round of name brain storming in our office. These names (some submitted, some we thought of) made the final cut.

• Be Agile, Go Mobile Conference 2012
• Adaptation: The Mobile & Agile Conference
• Adapt UX: The Mobile & Agile Conference
• BAM – Best Practices for Agile and Mobile
• UIE Trends: The UX Conference for Mobile & Agile
• Scrums and Thumbs: UX Conference for Agile and Mobile
• POP UX 2012: UX in Agile and Mobile
• UX Immersion 2012: Agile and Mobile

So how do you choose the right name, one that’ll be the forefront of the event’s brand? To make our decision, we turned to the same techniques we use for prioritizing large amounts of user data.

The Process

As with any good process, we first needed to figure out how we’d know if we did a good job. We needed success criteria. So we went about identifying the qualities of a good UIE event name.

As we looked at names we sorta liked and ones we didn’t like as much, we started discussing how they were different from each other. That gave us some perspectives: we wanted the name to be remarkable, but not too cute. It needed to be easy for someone to sell to their boss, since many folks will need to ask to come.

We knew that it had to convey the theme of the conference. A name that was easy to use in promotional materials. And that it conveyed it was associated with UX. In all, we ended up with a list of 8 attributes. But it would be impossible to find a name that matched all of those. So we needed a way to figure out which attributes were most important.

(Coming up with attributes like this is the same way we figure out what makes one study participant different from another, when we’re creating personas. We make playing cards for each participant, pull out two cards, and ask “What’s different between them?” and “What’s the same?”)

We used another technique from our client work: we gave each attribute a weight. Every person on the team assigned a number from 1 to 5, where 5 is a must-have quality and 1 is a nice-to-have.

To come up with a group consensus, we used a two-step voting process. First, everyone gives a number. Then we discussed any differences. (Why did Brian give that one a 2? Why did I give the same thing a 4?) Finally, everyone voted again (because the discussion changes people’s minds) and we chose the mode average. (Some people use median average, but that creates crazy precision that I don’t think is necessary.)

We then put our final cut of names through the criteria to see how they scored. Three names all scored pretty high. Our next step was to see how a designer would use the name in the logo. After seeing some initial sketches, it became clear what to name this new conference.

And the name is…

Are you ready? Here it is: UX Immersion 2012 Conference—Mobile/Agile.

It fit all our top criteria and we liked how we can easily shorten it to UX Immersion. (In the office we’ve already shortened it to IMUX or if you want to be Yoda like – UXIM.)

The web site will be up soon. In the meantime, if you want to get updates about the conference, sign up on our email list.

The Winners of the Contest

No one submitted this name directly, however four people submitted names that started with UX. No entries had immersion in the name. Since we can only have one winner, we decided to do a drawing among submissions from these 4 individuals. Congratulations to Gary Anderson. The other three people will receive runner-up prizes of the newly released UI16 OnDemand.

Finally, as promised, we drew three email addresses at random for the virtual seminar give away: Carol Roberts, Marci Kenneda, Chris Eklud.

Thanks to everyone who participated. Be sure to follow us on Twitter for the latest updates on the UX Immersion 2012 Conference—Mobile/Agile.

Opinion wars can get messy. They can stop a team in its tracks. And the worst thing about them is they can’t be won. There is never a winner in an opinion war.

The problem with opinion wars is their foundation. Let’s say you and I are in an opinion war. You strongly think that we should do some thing and I strongly think that thing absolutely the wrong thing to do.

For you to swing me over to agreeing with you that we should do that thing, you’d need to sway my opinion. And, if I’m going to convince you it’s wrong, I’ll need to sway yours.

However, swaying opinions is practically impossible. I’d like to think I’m a smart dude and my opinion is not just some random, unconsidered thought. Instead, I’ve based my opinion on my life’s experiences, which you haven’t had. Similarly, you’re a smart dude or dudette and your opinion is based on your life’s experiences, which I haven’t had.

To sway my opinion, you’d have to convince me to put aside everything my life’s experiences are telling me about this situation and take, completely on faith, your opinions. These are based on your life’s experiences, which I didn’t have. That’s really, really hard for me to do. It’s hard for anyone to do.

Opinion wars can’t be won. The only way to move past them is to subvert them.

Using Data to Subvert Opinion Wars

One way to subvert an opinion war is with data. In a design process, the data usually comes from user research.

If I believe there a right way to design something and your experience tells you that would be a sucky design, we have an opinion war. However, if we can get a prototype of that design in front of users, we’ll get real data to make the decision. We’ll no longer be working off our own opinions and experiences.

In almost every case where I’ve seen an opinion war, data about the users has completely dissipated it. Quite frequently, the data proves that neither side was completely right and that there was a completely different way to think about the problem.

All Hail The Arbitrator

Another approach to solving opinion wars is to appoint an final arbitrator. This person is chartered by the team to make decisions and every decision they make is final, no matter what others think about it.

We use this at UIE a lot. Each project has an owner. The owner makes all the final decisions for their project.

Often the project owner isn’t senior in the organization. In fact, they can be the person with the least seniority. They are not expected to ask permission. However, when they aren’t sure, they should ask advice.

Often the advice is conflicting and, occasionally, it’s strongly held. It’s this arbitrator’s responsibility to listen to all the advice and give it serious consideration. More importantly, it’s their responsibility to make the decision.

We’ve established a culture that says it’s the right thing to do make a decision, even if that decision turns out not to go the way people wanted. Even if that decision turns out, in the long run, to have not been the best approach. This is because a decision that moves us forward is better than getting stalled.

Opinion wars can kill a great project. Care needs to be taken to ensure they don’t get in the way.

Back in March 2011, Josh Clark presented a virtual seminar on mobile design where he discussed the importance of designing tapworthy mobile apps. In this article, we look at two of the questions addressed in the podcast follow up: Should content on mobile website differ from their big screen counterparts, and Josh’s opinion on native web apps versus mobile web apps. The follow up podcast covered even more material so you may want to give it a listen or read the transcript.

Read the article: Mobile Design- Content and the great Web-based vs. Native Debate

Josh’s virtual seminar on Designing Tapworthy Mobile Apps (which you can view a recording of) was so well received, we asked him to do another one. This Thursday, January 12, Josh is presenting Button Are a Hack, The New Rules of Designing for Touch. Learn more about this seminar.

Physicists figured this out, creating a data model of the rush-hour traffic. They then compared the data points to that of the moving spring. The results looked practically identical. They can use this information to help design new systems to relieve traffic congestion.

Models like this help us know how to design better. They tell us why the same patterns keep forming before us and give us hints to take advantage of their predictive behaviors.

Here are some of the models we regularly use here at UIE:

The Kano Model

Made by Noriaka Kano, this model shows us the relationship of a customers satisfaction to the effort and investment we make our designs. We use this model to predict when a feature is something that will delight our users and when it’ll be a basic expectation, and the most important point: most delighters eventually become basic expectations.

Market Maturity

One of the first models we created, this shows the stages a technology goes through, with regard to how it’s market receives it. We’ve used this model to understand how an organization’s management perceives the importance of user experience. It also helps us prevent fatal timing mistakes, where competitors can overtake market leaders because they miss important cues.

The Four Stages of Competence

Noel Bursch’s model that describes how someone moves from incompetence to skill mastery. This model is a recent favorite of ours for explaining how to help our users master complex designs.

The Magic Escalator of Acquired Knowledge

We created this model to help teams understand how users perceive a design’s complexity. It shows us how to simplify designs and what happens when we introduce major changes.

The Scent of Information

This model shows us how users move through an information-rich web site. We can use it to predict when a design is easy to navigate and where it’s putting up obstacles to users getting into trouble.

Core vs. Ring

An old model that we’re finding useful in today’s world, as it explains how people behave differently when they’re doing something that’s core to their experience versus something that’s ancillary. It helps predict how much someone will stick with a bad design and when they’ll just give up.

Hands vs. Brains

This model talks about the people teams want to hire and how to best employ them. It predicts why some smart employees struggle in some jobs while others thrive.

Design Decision Styles

This model outlines five different styles for making design decisions. Using it, we can identify what a team needs to do to inform their decision making process. It also helps us tell when there’s a mismatch in the team’s composition or approach.

When we’re working with teams, we regularly mix and match the models. Complicated problems can usually be explained by combining several models, until we get new ideas for the solutions that move us forward.

What models have you been using? How are the useful?

That doesn’t mean co-located teams will always succeed – they don’t. It doesn’t mean that remote teams will always fail – they don’t either. In fact, we’ve met some awesome teams where team members are remote. (The folks at EightShapes immediately come to mind!)

Design is hard. Great design is really hard.

Teams need to rally every bit of energy they have to work together to produce great designs. They need to talk with each other. They need to see each other’s work.

We’ve observed that teams that work closely together create a common vocabulary. That vocabulary creates words and phrases that separate good design decisions from not-so-good ones. It helps the team discuss what’s on track for their design, versus what’s a distraction.

It’s also critical that teams is regularly discuss their emerging vision. This vision gives team members direction when making tough decisions. As things tiptoe up the borders of that vision, the teams needs a channel for expressing their thoughts.

Teams working remotely limit their communication channels. (This is even worse when the time zones are skewed, especially for those teams that span across oceans.) Establishing the common vocabulary and reinforcing the vision becomes increasingly difficult with remote teams. It’s not impossible, but the amount of extra effort is formidable.

We’re still collecting and analyzing our data on this, but our early results seem very clear. You’re more likely to produce a great design when you’re all in the same space, talking to each other. (War rooms are great for this, especially if you have lots of wall space to hang work-in-progress and have impromptu discussions.)

The next best thing is to have everyone be remote, but in the same (or a very close) time zone. Physically getting together at regular intervals can help quite a bit. (It’s even more helpful if your first project can be co-located.)

Teams talk about using remote conferencing tools, but they aren’t the same. The weird delays that come make simple things like telling a joke more difficult. These meetings adopt a false sense of formality because the changes in how the group interacts. It’s an expensive substitute that doesn’t really live up to its promise.

From our data, the worst case scenario seems to be when some people co-located and some remote. The remote people, not privy to the local conversations, become a type of second-class citizen. These teams seem to have the most trouble producing great results.

If you have any say in the matter, you want to aim for a co-located design team. If you can’t do that, then forcing everyone to be remote might be the next best option.

This is really hard for organizations that aren’t located where all the good talent is, or for those designers who are in places where they can’t be near the rest of their teams. Unfortunately, we’re not seeing any good options here for those folks.

It sucks, but those teams face a much harder challenge that teams that have the luxury of co-location. Great design is hard enough when we’re all in one place.

Hidden interactions often frustrate users, as can be seen in any number of the online forums where game players get stuck with puzzles like this one. It’s even worse for non-game applications, where users aren’t interested in solving challenges, instead focused on getting their work done.

Gesture-based interfaces, like those we see in the growing world of touch interactions are often included without any visual clues for the users. How are users supposed to know they can take advantage of them?

In today’s UIEtips, I share some of the discussion Josh Clark, author of Tapworthy, and I had around this topic. We explore what the new world of touch gestures brings to designers, and how they have to be prepared for the demands of this new technology. Josh and I got into several important issues about how designers need to develop a new sense of touch, as it were.

Read the article, Developing a Designer’s Sense of Touch.

Next Thursday, you’ll want to join us for Josh’s new UIE Virtual Seminar, Buttons Are A Hack: The New Rules of Designing for Touch. Josh will show you how touch takes us beyond the desktop metaphor and buttons, and what you need to know to design for that journey. You don’t want to miss this!

Look at any young and accomplished musician or artist. Or at those twenty-something sports stars. They are obviously talented.

Yet, how much of a role does their talent really play in what they do?

That 12-year-old pianist who is dazzling the audience with her Bach concertos – sure, she has talent. But look closely and you’ll see someone who has been practicing for years. She took classes and sat at the keyboard for hours every day.

While talent is something we’re born with, skills are something we pick up. Study hard, practice often, and given enough time, a person achieves mastery.

In design, this is certainly the case. I’ve met designers who demonstrated their stuff easily, but most of them did that after years of practice. They worked hard to learn the tools, to become literate in the ways of design. They always study the work of others, first by mimicking to master the technique, then adopting it to make it their own style.

It’s true that talent may get them to mastery faster. It might push their mastery beyond that of their peers.

Yet, everyone I’ve met who is really great (and I’ve met a lot of great designers), got there because they worked at it. It wasn’t natural.

Breadth of experience is another thing those great designers all share. Mixing up the projects, mixing up the teams they work with, mixing up the customers they design for – all that brings experience.

Every time they change something up, they have to re-evaluate what they believe to be true. They have to tweak their skills to the new environment. What used to work well now doesn’t work as well. They have to ask, “what do we need to do differently?”

Hang around me long enough and you’ll hear me utter one of my favorite aphorisms: “Good judgement comes from experience and experience comes from bad judgements.” I’ve observed that great designers make smart decisions quickly. They have years of practice at making decisions. They have a breadth of experience. They can recognize important patterns. They constantly practicing their basic skills.

Don’t worry that you’re not talented enough: get out there anyways. Learn the skills. Practice them constantly. Change up your environment to gain new experiences. This is the path to being great.

Talent only differentiates us when we’ve already mastered skills and had a breadth of experiences. What separates the great designers from everyone else today isn’t their talent — it’s their skill and experience. Talent is the least important of those three attributes.

What’s the difference between contracting and consulting? One major difference comes down to whether the job is handwork or brainwork. Whether you’re an “innie” or an “outie,” this is applicable.

Innies are UX professionals who work inside an organization. Even though they are part of the company, they are still consultants. They are brought on to projects with the intent of lending their skills to move the project forward. Sometimes they stay with one project for its duration, or sometimes they juggle multiple projects at once. Either way, they aren’t really part of the long-term team in the same way others are — they move from team to team and are only there when their skills are in demand.

Handwork and Brainwork

Innies and outies have a lot in common. One thing they share is the need to distinguish whether a project is handwork or brainwork.

Handwork is when the hiring team knows what they want; they just lack the right number of hands to get it all done. Let’s say the team needs new screens designed. They know what the screens are and how they should work. They’ve built many screens before, quite successfully, so it’s not a problem of knowing what to do.

The problem is they don’t have enough hands to get the job done. All of their internal resources are otherwise occupied, thereby stalling the screen-production piece of the project. In this case, they hire a contractor—someone who will come in and help them crank out more screens. This is handwork.

But there’s another way the project could go down. What if our hypothetical team doesn’t know what the screens are or how they should work? What if they don’t have the experience of building screens before and lack the confidence and skills to get started efficiently?

In this case, they need someone to help them come up with a strategy for identifying which screens need work and how to tackle them. In fact, once that strategy is set and they understand what the project needs to be finished, they may have, internal to the team, all the resources necessary to complete it.

This is when they hire an outside consultant; someone who will bring in expertise and skills the team doesn’t otherwise have. This we call brainwork.

Hiring Hands and Brains

It’s quite critical, as a UX consultant (whether you’re an innie or outie), to distinguish between handwork and brainwork—yet the distinction is often not discussed. As I talk to people who are looking to expand their careers, what I discover is they are often trapped doing handwork when what they really want to do is brainwork. (Occasionally, I meet someone who prefers to do handwork to brainwork, but that is quite rare.)

Handwork, for the most part, is commodity work. Once you qualify the basic skills, it really doesn’t matter who does it. It doesn’t take imagination. Previous experience, for the most part, doesn’t play a role in the quality of the output.

If the team needs to produce 100 wireframes and they have a pool of 20 people who are capable of producing those wireframe to their specifications, then it doesn’t matter which of those people you hire. Hire the one who charges the lowest rate, has the nicest personality, and produces the cleanest deliverables.

Brainwork, on the other hand, is where your expertise and experience come into play. If the team doesn’t know what a wireframe is or how to decide what they should do, they’ll want someone who can give them solid advice. It they’re smart, they’ll be selective about who they hire, looking for someone with a track record of helping other teams in comparable situations, and they’ll pay top dollar for their help.

Maybe the team’s leadership is mistaken and they shouldn’t be doing wireframes at all? Well, someone hired to do brain work will have earned the respect and authority to say, “You know, there’s a better way to do this” and the team will listen. (Occasionally, they’ll even revise their plans, but that’s another column for another day.)

However, if that same person was hired to do handwork, there’s no way the leadership will pay attention. It’s wasted breath (or worse, seen as belligerence that may result in removal from the project). Handwork is hired for hands, not brains. Please keep your brains to yourself.

UX professionals who do handwork are what we call the Hands. They’re a rare and valuable breed. Find someone who loves being the Hands and you have a production machine.

The Brains are what we call folks who provide great brainwork. Prospective employers have to be more discriminating when hiring the Brains, because their advice will drive the results, either to success or to failure.

Hiring managers should know which they want. Get the right person for the job and you’ll have a successful project. You need to distinguish between Hands contractors and Brains consultants. In the next installment, I’ll talk about the qualities that separate a great Hands contractor from a great Brains consultant.

[Don't forget to read part 2. After this article was originally published, there was a little confusion. I try to clear it up here.]

Fast Forward Four Months…

We’d like to thank you for doing a fantastic job as our 2012 Winter Business Intern. You started with a thorough analysis of the purchasing patterns in our UIE Virtual Seminar series. This led to some amazing insights on how we could restructure the program, which helped us with key initiatives we launched this spring.

At the same time, you put together a marvelous weekly social media outreach strategy. Once you started executing it, we saw a real lift in the conversations we’ve had with our customers, which has had a direct affect on our bottom line.

When you turned your keen attention to compiling the history of our revenue sources for the last few years, you uncovered some interesting patterns about who our customers are and how they like doing business with us. We’ll use those insights to drive new products for years to come.

You also created a database of our marketing partnerships, to help us know who to contact and what they’re interested in. This makes it easy for us to make our partners aware of our latest offerings.

To top it off, you’ve even helped us document our business development process to make life easier for future interns.

Thanks for your energy and enthusiasm during your internship. We know you’ll succeed at your future ventures.

Now Back To Today…

If you’d like this to be your story, send us your resume with a half-page write up of your most significant business accomplishment. While we’re less concerned with your skills and qualifications, we won’t compromise on your ability to deliver team results. We’ll be back to you in 24 hours if you have what it takes to achieve something special.

You might even want to check out our web site for some insight into what we’re doing. We think you’ll be excited by where we are today and the challenge to get us where we’re going.

You will work in our North Andover offices. (Sorry, we don’t hire remote employees.) We’ll provide all the equipment you need, including Apple hardware and Mac software to bring out the best in your talents and skills.

Send your resume and write-up to: BusinessInternJob@uie.com

or

Jared M. Spool, CEO
User Interface Engineering
510 Turnpike Street, Suite 102
North Andover, MA 01845

Fast Forward Four Months…

We’d like to thank you for doing a fantastic job as our 2012 Winter Web Developer Intern. You’ve driven the launch of a new web site for our latest conference. You worked your magical HTML5, CSS3, and Javascript/JQuery skills to get us a slick, good looking, easy-to-use site. You updated it with new content as we got closer to the event and, because of you, the event was a success.

Your site development skills are top-notch. You’ve helped us clean up some of our old PHP server scripts, removing outdated advertising and content from the site.

You also helped us migrate our UIE Virtual Seminar pages to our new ExpressionEngine-based Content Management System. We were impressed with how quickly you picked up on what we were doing and the improvements you made.

To top it off, you’ve even helped us document our Git-based design and development process to make life easier for future interns.

Thanks for your energy and enthusiasm during your internship. We know you’ll succeed at your future ventures.

Now Back To Today…

If you’d like this to be your story, send us your resume with a half-page write up of your most significant web development accomplishment. While we’re less concerned with your skills and qualifications, we won’t compromise on your ability to deliver team results. We’ll be back to you in 24 hours if you have what it takes to achieve something special.

You might even want to check out our web site for some insight into what we’re doing. We think you’ll be excited by where we are today and the challenge to get us where we’re going.

You will work in our North Andover offices. (Sorry, we don’t hire remote employees.) We’ll provide all the equipment you need, including Apple hardware and Mac software to bring out the best in your talents and skills.

Send your resume and write-up to: WebDevInternJob@uie.com

or

Jared M. Spool, CEO
User Interface Engineering
510 Turnpike Street, Suite 102
North Andover, MA 01845

There’s value in listening and reading everything we produced in 2011. But we know time is a factor. So in the last UIEtips for 2011, we decided to share the 5 most popular blog posts and articles.

Here they are, in no particular order, the most popular articles and blogposts published during 2011.

Why I can’t convince executives to invest in UX (and neither can you)

Blog post published June 8, 2011, by Jared M. Spool

Every few weeks, a phone call or email comes out of the blue, asking me to perform magic. The inquirer always wants the same thing: to stand up in front of a room filled with their executives, delighting them with a presentation that will make them rise to their feet cheering. This audience will then burst out of the room, demanding their subordinates to invest everything in a whole-scale, no-holds-barred user experience effort that will revolutionize the company, the products, and the world.

OK, maybe I’m exaggerating a little. But I am quite frequently asked to convince executives to invest in user experience.

And it may surprise you to learn that I refuse the offer every time.

Read more about Jared’s rationale behind, Why I can’t convince executives to invest in UX.

6 Epic Forces Battling Your Mega Menus

Published August 24, 2011, by Jared M. Spool

“This is a perfect opportunity for us to use that mega menu we wanted to try out.” That’s what I heard a few weeks ago, sitting in a client meeting.

The client was dealing with balancing a lot of navigation while keeping their home page free for the important messages they want everyone to see. A mega menu – those large multi-column layered menus that pop up when you hover over the navigation – seemed like just the ticket.

However, our research shows mega menus come at a price. In this article, I talk about the epic forces that are constantly in battle with any mega menu implementation, preventing the users from getting value.

Read the article, 6 Epic Forces Battling Your Mega Menus.

Beans and Noses

Blog post published July 8, 2011, by Jared M. Spool

Over the years, I’ve received a lot of great advice. One piece of advice I keep coming back to is about managing expectations. It came from an old friend, just a few days after I’d started my consulting practice.

He was a seasoned consultant himself and I had asked him what I should know, just starting out. He told me his First Rule of Consulting:

No matter how much you try, you can’t stop people from sticking beans up their nose.

That was it. Beans up the nose. Really.

At the time, I thought he was nuts. Now, I’ve come to realize those are words to live by.

Find out more on what Jared means regarding beans and noses.

Creating Great Design Principles: 6 Counter-intuitive Tests

Published March 1, 2011, by Jared M. Spool

The excitement in the room was electric. Everyone was waiting for the big moment. Finally,
it was here.

For six months, the team had been working on their new design principles. In closed meetings, they were hashing out what they were going to do and how it would be different. Now, the project manager was walking to the front and revealing the fruits of their labors.

Easy to use. Enjoyable. Innovative.

People were shuffling in their seats. Really? Six months for this? “But, we’ve got executive buy-in. That took a lot of work,” the project manager defended. Right, because who could argue against ‘innovative’?

We’ve seen this scenario play out way too often. Teams create principles that prove too generic to be useful in any design decisions.

Learn about the six tests that separate out generic design principles from those that really work for a team in the article, Creating Great Design Principles: 6 Counter-intuitive Tests.

Do Users Change Their Settings

Blog post published September 14, 2011, by Jared M. Spool

Back in the early days of PC computing, we were interested in how people used all those options, controls, and settings that software designers put into their applications. How much do users customize their applications?

We embarked on a little experiment. We asked a ton of people to send us their settings file for Microsoft Word. At the time, MS Word stored all the settings in a file named something like config.ini, so we asked people to locate that file on their hard disk and email it to us. Several hundred folks did just that.

We then wrote a program to analyze the files, counting up how many people had changed the 150+ settings in the applications and which settings they had changed.

What we found was really interesting.

Read more about what our research discovered.

I’ve been thinking about this question for a while now. Something was bothering me and I think I’ve figure it out.

Instead of thinking about ‘early adopters’ and ‘normals’ as if they are two homogeneous groups, I think it’s better to look at the motivations that trigger someone to buy into a new technology or solution at various points in the release timeline.  Here’s some of our research findings, as we try to understand when people take to new stuff:

People Who Are First

In our research, we’ve found three main reasons that someone adopts a product or service early on.

Being First to Gain Social Status

Many of the answers describing early adopters are talking about a select group of people who are the first to acquire new technologies and solutions — those with the motivation to be amongst the first. In our research, there are common themes of drivers for this motivation. 

These individuals tend to drive their social status by knowing the latest-and-greatest in what’s happening in the tech space. The people we’ve interviewed tell us they enjoy the thrill of having something before others, of knowing details about what’s happening, and of partaking in the ‘insider’ community of the tech world.

For these individuals, it’s a passionate avocation, sometimes professional, to collect and promote their newest items. They don’t need the products for what they do, they just want them to be at the leading edge of use. You can think of it like movie reviewers — they go to practically every movie, to serve as an informed authority for others in their influence circles on how good it is and what the salient features are.

These folks aren’t very loyal customers. In our research, they infrequently use something once another item comes out to replace it. (Plus, if they develop enough of a reputation, they are often given the first version, so they don’t even provide the initial revenue.) They are, in effect, an extension of the marketing machine for the product.

Being First as Product Research

There’s another group we found in our research: those folks who want to be first because they need to keep up for professional reasons. They are almost always in the tech community (or in fringe communities, like financial analysts that study the tech world). They buy the new to understand the core of the innovations that are happening.

Their interest isn’t in use, but in reverse engineering, on some level. They want to see what makes it tick and how to exploit any good ideas for other projects they may have.

These aren’t very loyal customers either. They don’t really care about the product or the company that made it, beyond what salient innovations they can take away.

Being First to Solve An Active Need

Unlike the other two categories above, this group jumps at a new product or service because it promises to solve a need they find very pressing. For these folks, they’re currently feeling pain and the new product or service is a solution.

Recently, we’ve seen this with the Toyota Prius (need: be more environmentally friendly and reduce gas consumption), Apple iPod (need: have music more available), Apple iPhone (need: a better mobile experience), TiVo (need: time-shifted television watching), Dropbox (need: share files across devices and with colleagues), and Cirque du Soleil (need: a grown-up circus).

What’s interesting is the folks who buy into these products early on don’t typically buy into just any products early. They have a real need and are willing to take the risks of the early product to resolve it.

This group isn’t responsive to brands per se, though a successful outcome will strengthen brand engagement. They don’t automatically buy other products from the same brand. (For example, most strongly-pleased iPhone customers didn’t purchase Apple TV, even though it’s a sister product.)

In some cases, the active need is because their existing solution is slowly killing them through what we call the “death of a thousand cuts.” They are feeling increasing pain with their existing solution and are looking for any compelling reason to move away.

Of the three groups I’ve mentioned so far, this is the only one who actually uses the product for more than experimentation. Unlike the other groups, the folks in this group’s successes and pain points are similar to what you’ll see with later groups. These are the folks to design for.

People Who Wait

What you’re calling the “normals” are people who wait to purchase after a new product or service is introduced. Like the folks who buy immediately, our research has shown there are several types of these people.

Waiting Because Unaware of Latent Needs

Like the folks solving for an active need, these people also have a need for the product or service. The problem is that they don’t realize that need yet. They are experiencing the same pains, but they haven’t actively identified that a solution exists, let alone the product or service that’s on the market.

Often, it isn’t until someone close to them, who encounters the same pains, shares how they’ve solved it with the product or service. Since they aren’t looking for the solution directly, they often are immune to any marketing beyond word-of-mouth. Even then, they might have to hear it from several members of their cohort before they act.

For these folks, the design needs to help convert the latent need to an active need. Once these people see the benefits from the point of view of an active need, they’ll be more likely to try out the product or service. The first interactions with the product or service need to address that need directly, without any friction or interference.

Waiting Because Of Perceived Cost Of Change

Change is costly for folks. For that reason, many typically approach it cautiously. Since people remember pain more vividly than pleasure, the pain of their previous changes are often upmost on their mind. A new product or service has to talk directly to the pain from that change to reach these people.

The cost of change comes in many forms. There’s the monetary implications of purchasing something new versus keeping the old thing. Free trials and other “try me” promotions can help with the money, but don’t get over the other forms automatically.

Also, there’s a cost of moving data and procedures to the new thing. For computer-based products, people have a ton of data they’d need to migrate over. They also have routines and rituals in their life that make the transition difficult. (For example, someone moving from one email client to another has to adjust their morning-check-and-reply rituals.) Designers who plan out this transition do much better than those who leave it to the user to figure out.

Another cost of change is the loss of competence with the new product. Using their existing solution, they’ve accrued a comfortable competence level that lets the product or service disappear, while the new one they have to learn everything all over again. (One of the smartest things Microsoft ever did was, when releasing Excel 3.0, creating a separate manual called Microsoft Excel for Lotus 1-2-3 Users. This guide directly translated the competence of the Lotus user to the new product.)

Waiting Out The Product Lifetime

A small, but firm group are the folks who, once have a working solution, will refuse to change until the product or service completely dies and is no longer an option. These folks will resist any new product or service until whatever they are doing just can’t be done.

Now I look at the basic usability test protocol like it’s a column of wet clay, ready to be molded into exactly the research instrument we need. Over the years, we’ve invented, borrowed, and stolen different variations, all to help us better understand our users and what we’re designing.

In today’s UIEtips, I talk about five of our favorite variations. You’ll see how we bend and twist basic techniques to discover new things about what we’re designing.

Read the article: Bending the Protocols – Useful Variations on Usability Tests

What are your favorite variations on usability testing? Tell us below what you’re doing.

In our research, we found successful design teams have each team member spend a minimum of two hours every six weeks watch real users interacting with either their design or a competitor’s design. The most successful teams have even more frequent exposure hours.

When team members watch someone use the design, several things happen. First, they gain empathy with that person — empathy that makes them sensitive to frustrations and delights the design imparts. That empathy is critical for setting design priorities, as we try to eliminate those frustrations and amplify the delights.

Second, the team picks up the culture of use. They learn the language the users use. They learn how users approach different parts of the design. They learn the goals of the users, and how the design fits into the users’ daily life.

Third, the team develops a design language to describe the differences between good and bad. Having the real experiences of real users as a common understanding breaks each team member of always referring to their own experiences. Instead of saying, “this is how I’d use it,” they can now say, “this is how Mary, who we saw last week, might use it.”

Fourth, because the exposure happens frequently over a long period of time, the team members see how their design attempts are working. It creates a feedback loop in their design process, where they learn when their design changes created the improved user experience they were seeking.

Innovation happens when you add value for the user. Teams with more exposure to how real people use their designs can more easily see opportunities for innovation. They can try new ideas to whittle away the users’ frustration and see how those ideas pan out. This makes them smarter and more informed, so they make better decisions in the long run.

In our research on personas, we’ve found this works best when the personas are based on real people doing real things. We regularly take teams into the field to meet their users and watch them interact in their own environments. We then capture the interesting bits to assemble our personas. We know we’ve done a great job when we can point to any element of the persona description and talk about the different real users we observed, doing and saying the same things.

What happens when we can’t do the research with the real users? Tamara Adlin does something she calls Ad-Hoc Personas, where the team gathers all the information they already know without doing any new research. Kim Goodwin does something similar that she calls Provisional Personas.

Because we often already know a lot about the people we’ve been selling our product to and supporting, we can build a decent picture of what they are like and what they need. If we combine different viewpoints, like those from sales, training, and support, it’s possible to surface a lot of interesting details to design with.

However, these aren’t as rich as the fully-researched personas we started with. It’s hard to separate out the mythology that forms around users from the reality. The advantage of going into the field is we can see where that mythology breaks down.

It’s possible we could go even farther away from the research by creating personas that are complete fiction. The team could ask, “What do imagine users might be like?” and “What do we think those users might do?” I guess it’s possible personas crafted from complete fiction like this can inspire the team to innovation, but it’s likely not better than self design, which would at a minimum have checks and balances of contact with someone using it.

The “persona purists” argue that completely fictional personas aren’t real personas at all. Their argument is that when we dilute the research component that goes behind the persona, we take risks that a design built from those personas won’t fit the needs of real users as well.

At UIE, we’ve seen multiple teams go down this fictional road, then end up with descriptions that nobody believed in. The team didn’t rally around it and the personas turned out to be a wasted effort. Because they were labeled “personas”, it was impossible to get those teams to buy into a subsequent well-researched persona project. They were completely turned off by the idea of personas and were against any future investment in them.

Should we come up with a different name for those things we create from pure fiction, like “user caricatures” or “fictional users”? (When I asked Kim Goodwin if she had a name for completely fictional personas, she called them “creative writing class exercise.” That sums it up pretty well, I think.) Should we go to efforts to explain that things without research aren’t personas?

What about the Ad-hoc Personas or Provisional Personas? Should we stop calling them personas too?

We don’t want personas to become diluted so much that the term doesn’t have meaning. How do we protect the value of these tools without getting lost in semantic mumbo-jumbo?

Ok, that’s kind of a lame riddle, but it’s accurate nonetheless. When we get a wrapped present, we hope the unwrapping will produce something that delights us.

The same is true when clicking on a search result. We anticipate it will serve our needs and provide everything we’re seeking.

Unfortunately, much of the time, it doesn’t. The shame is it’s completely preventable—careful thought and design could’ve resulted in a delightful user experience.

In today’s UIEtips, we look back at an article from December 2009. I talk about some perils we’ve seen when users clicked on sponsored links, only to be disappointed by the results. Two years later our findings are still the same.

Read the article, Three Perils with Search Landing Pages.

How do you determine what ads to show when search is involved? Share your thoughts with
us below.

Of all the major airlines, United has the best service out of Boston. The only other options if you need to travel all over the country are American, Delta, and US Airways. Those three options deliver far worse service than United does.

This means, if I was included in a UA Net Promoter survey, I’d give them a 7 or above. That’s a good score for Net Promoter.

My score is a great demonstration of why Net Promoter doesn’t work. You see, I hate United Airlines. With a passion. As airlines go, they are really quite bad. I fly them almost every week and almost every trip, I have some experience with poor service and a bad relationship. Granted, there have been some trips where nothing bad happened, but nothing remarkably good happened either.

However, my trips with American, Delta, and US Airways are much worse. I will continue to fly United until someone better comes along, but I don’t expect that to happen any time soon. (I do like Virgin America a lot, and JetBlue or Southwest, but they don’t fly where I need them go as reliably as United, so I can’t use them often.)

I’m not recommending United Airlines because I like them. I’m recommending them because they are better than the other choices.

Net Promoter isn’t scoring my loyalty, because I’m not loyal. (I’m trapped, which is quite different.)

It’s not capturing my overall dissatisfaction with the airline. In fact, if everyone answers the survey for the same reasons I do, they look pretty good.

I think Net Promoter Score is an ineffective instrument for measuring how your customers feel about you. A better instrument is something more rigorous, like the Gallup CE11 Customer Engagement Score.

The CE11 has eleven questions, which we weight (as a Guttman Scale), including a Net Promoter-like referral question. But that referral question is weighted low, with questions like “Do you think [the brand] would take care of you if there was a problem?” or “I’m proud to be a customer of [the brand].” There are businesses that I’d score high on these other questions, but United Airlines wouldn’t be one of them.

These days, many of our clients are relying on the Net Promoter instrument (and its close brethren) to assess how they are meeting their customers needs. We warn the teams we’re working with to be careful — they may not be getting a complete picture of what’s happening and how their customers are experiencing their designs.

During the spring of 2012, (hint: probably late April) we’re producing a new conference. We’re still putting it together, so we can’t share too many details.

I can reveal this: It’s gonna be about the best practices around designing mobile and incorporating agile into your work environment.

Over the 3-day conference, attendees will choose from a variety of full-day workshops, 90-minute talks, and keynote presentations. It’ll have the kind of field-leading, edge-defining, top-caliber speakers you’ve come to expect from a UIE event, jam-packed with techniques to immediately make a difference with your designs and inspiring insights.

It needs a name. The MoAgile Thingy just doesn’t flow right.

We don’t know what to call this 3-day thing. For lack of anything better, we keep calling it the “MoAgile Thingy”, but we’re dubious that’ll play well outside our walls.

Unlike the last year couple years, this won’t be a conference that goes on tour. This new conference will only occur in one city during 2012.

Give our Thingy a name. Win a free registration.

Would you like to come to our Thingy for free? If so, help us find a better name.

We’re holding a contest. If we like your name, you get to come for free. And 3 people who enter will win a free UIE Virtual Seminar of their choice (live or a recorded one).

Send your entries (as many as you want) to contest@uie.com by midnight (EST) on December 22, 2011. Any ideas are good ideas.

We’ll pick three email addresses out of all the submissions at random and send instructions on how to pick your virtual seminar.

And, if we love your event name enough to use it, you can be our guest at the MoAgile Thingy (or whatever you called it)! How cool would that be?!? (You’ll walk around the event, pointing at every badge and sign, telling everyone around you, “I came up with that!”)

Please, help name our thingy and send your ideas by midnight, December 22!

She concluded her post with this comment:

I’ve grown tired of people taking common sense, labeling it and then trying to christen it as a new process.

What jumped out at me was her implication that, just because it’s something she’s been doing, it must be common sense. I’ve heard this sort of thinking a lot. I guess it depends on the definition of common sense that you’re using.

There are two definitions I can see here:

1. Common sense is what I know to be true and how I judge the world.
2. Common sense is what is most commonly believed to be true and how most people judge the world.

These two definitions can only be simultaneously true if I believe the same things as the majority of people out there. Otherwise, they are in conflict.

Now, I’m at an interesting vantage point. As a researcher, I study what people believe. One area I study is what designers believe, particularly about creating great designs.

What I’ve learned in my research is that there are lots of different beliefs out there. Finding a majority belief is rare. And often, when we do, it’s not something that makes for the best designs.

Many folks are looking at Lean UX right now and saying what Lorena is saying: “It’s something I’ve been doing for years. What’s the big deal? Why do we have to give it a special name?”

But it’s not something the majority of teams I study are doing. Most are doing something more waterfall-ish, even when working in an Agile or Agile-ish environment. To them, this thinking is new. It’s novel. And it’s certainly not, from their perspective, common sense.

There’s an old saying: “There is nothing more uncommon than common sense.”

I’m wondering if we play the “it’s just common sense” a little too quickly and if that hurts our work.

Unconscious incompetence is the first of the Four Stages of Competence. In this stage, someone doesn’t realize just how much they don’t know. It’s a blissful state and, frankly a place that is wonderful.

Imagine not knowing what you don’t know. You can do practically anything you want and never run into the boundaries of quality. (As my former work colleague, Will Schroeder, used to say: “Once you remove quality from the requirements, everything becomes a whole lot easier.”)

Lots of what we call “unintended design” — design that’s the result of people focusing on the internal architecture or outside requirements instead of on the users’ experience — is the result of unconscious incompetence. When a team produces a horrific design, they don’t realize there’s a better way.

When I started in the computer field, almost all design was this way. Whatever way the code fell was how the design ended up. If the user had to jump through hoops to do simple things, well, too bad. They’ll learn how to use it in the training or read the manual or something. Or they’ll write up a software bug report and we’ll do something to fix it. (Or dismiss it as a PEBCAK error.)

An organization can get away with unconscious incompetence as long as all of its competitors are the same way. However, once a competitor becomes competent, the ballgame changes. Suddenly, there’s a pressure to learn what it takes — to become competent at the design process themselves.

It’s this transition that we see lots of organizations today. They are moving away from the bliss of not knowing to the stress and frustration of suddenly realizing there’s a ton they don’t know. It’s a painful transition, but one that is the start of an often fruitful journey.

What’s really fascinating about this article is the back story. The client had hired us because they were concerned about checkout-process abandonment. Their analytics were showing a 13% drop off in sales, which, based on the average value of the abandoned shopping carts, was worth about $1.2 million a year in additional revenue.

Checkout-process abandonment is common in e-commerce sites and something that you can easily detect with your site’s usage logs. You just look at the number of people who get to the first screen and then the number of people who actually complete the transaction. Everyone who doesn’t make it is considered an abandoned cart.

When the team contacted us, they’d already pretty much decided what the problem was and how they were going to fix it, even though they had never watched any shoppers make purchases. And they were dead wrong. Not only was their fix not going to help, our research showed that it was going to increase abandonment.

Two weeks of usability testing on the live site (and on competitors’ sites), followed by two weeks of iterative paper prototype testing produced a streamlined checkout process, which, once implemented, showed a dramatic increase in revenues. It’s amazing what you’ll learn when you actually watch your users.

Today’s article talks about the bulk of that increase — how a simple change to a common screen produced $300,000,000 of additional revenue over the next year. I’m sure you’ll find it interesting.

You can also read more on the back story of the $300 Million Button on the Brain Sparks blog.

Have you seen results from changes to your forms? We’d love to hear your experiences. Share them with us below.

As our clients are moving to more rapid development processes, like Agile’s Scrum, their design teams are looking for ways to infuse their UX work into the process. My recent research shows that Lean UX is one way to get there and it’s getting lots of traction through out the UX community.

In this week’s UIEtips, I discuss what’s been happening to our design processes and why I think Lean UX has real potential to change the way we approach our work. I’m sure you’ll enjoy it.

Read the article: Is There Any Meat on This Lean UX Thing?

As an extra bonus, coming up on Wednesday, December 7, we’ve invited Jeff Gothelf to talk about how he’s using it to get his company, The Ladders, out of the deliverables business. If you’re working in Agile or another fast-moving environment and want to know core essential techniques for good design, you won’t want to miss this virtual seminar. Read the details.

What’s your take on Lean UX? Is it something you’ve been working with? How has it helped you? Share your thoughts below.

I’ve met many of unconsciously competent users in my research. They are fast and efficient. When people talk about “power users”, these are the folks they have in mind.

Now, imagine what happens when you make a sudden, major change to your design — a change that rethinks and redistributes all the functionality and the way it’s used. Suddenly, those unconsciously competent users can no longer rely on their knowledge of the design. They have to think about things that they never had to think about.

That severe change you made to the design rendered those users, at best, consciously competent, and, at worst, consciously incompetent. They now have to think about how they get their work done, in addition to what they are trying to do.

In the worst case, they can’t figure out the new design because it’s so radically different from the design they are used to. Even if the new design is more efficient than past designs for other users, these users are rendered helpless because they are forced back to a world where they have to learn the interface.

This sudden loss of competence is even worse when, as often happens, there is no new functionality in the design. They are slowed down and made to feel incompetent without any new benefits.

If you really want to piss them off, do this as a software as a service (SaaS) automatic upgrade where they get no choice on the timing. At least, when a desktop app makes this type of severe design change, the user controls when they install it. But with SaaS, the service provide decides on the transition date, often without any warning or preparation.

If you’re wondering why your most effective users are really upset about sudden upgrades, I’d look to a sudden loss of competence.

As we study what makes teams successful, we realize that the successful teams aren’t doing anything new or novel. Their success is solidly based on a fundamental that many of the struggling teams have forgotten: good design decisions come from informed members of the team.

A significant difference that’s come about in this new agile world is team integration. No longer is UX design owned by the UX designers: everyone on the team now has design responsibilities. That means that everyone needs to understand what the design is trying to do.

When we talked to the teams from the successful organizations, we found a common theme: they used a framework to make sure their teammates have all the information they need. We’ve codified this framework as UX Layers, which span from the big picture of a long-term vision all the way down to the details of individual user stories for developing the next sprint.

In today’s UIEtips, we look back at an article from May of this year. We explore the UX Layers, looking at how they each fit together. Whether you’re currently doing Agile development, planning to move there, or still working in a waterfall world, I think you’ll find this framework will help ensure you’ve got all the information you need to create great designs.

Read the article, Essential UX Layers for Agile and Lean Design Teams.

Want to know more about how Lean UX contributes to working faster, smarter, and happier? Explore our next UIE Virtual Seminar on Wednesday, December 7 with Jeff Gothelf, Lean UX: Getting Out of the Deliverables Business.

Has your team tried a similar framework for ensuring every team member is making informed decisions? Let us know your thoughts and questions below.

Now, what they are building is usually some made-up project, constructed to practice the techniques. The actual results of the design don’t really matter, but, in a great workshop, the students become engaged and put a lot of energy into what they’re building.

At the end of the workshop, they want to show all their hard work. And everyone wants to have a glimpse of what the other folks in the class have done, to see how their design compares to other efforts.

In my workshops, I’ve tried a bunch of different approaches to the sharing. I’ve held walk-around show-and-tell, where people stand by their work. It’s like at a poster session or science fair, while others see what’s they’ve done. Unfortunately, the person who has to explain the work doesn’t get to see what others have done.

I also have tried having each team give a short presentation. It’s interesting for the first couple, but then, because everyone has worked on the same thing, it starts to drag on. Presenters don’t stick to their time limits and their presentations tend to be dry. The pain is compounded because all this happens at the end of a busy day, when everyone is exhausted by being in an all-day workshop.

Kevin Hoffman has a unique way of handling this. In his UI16 Workshop on Conducting Effective Kickoff Meetings, he had his attendees work on a design to practice the various kickoff meeting techniques he was teaching. At the end of the day, they’d all worked hard on their projects.

To show their work, he had them give presentations, Pecha Kucha style. That means they have to give their presentations using 5 slides which automatically advance every 30 seconds. One slide is a picture that Kevin took of their work, while the other four slides are clever art that the visual designers at Happy Cog put together. They don’t see the slides until the audience does and then have to make up a tie-in to their thinking, right on the spot.

The result was an entertaining set of short presentations. We got to see the work, while people had some fun improvising to the slides. Because Kevin only does this with four teams, it goes by very quickly.

I’ll be using the Pecha Kucha style presentation in my next project-based workshop.

[Update: Kevin tells me he borrowed this technique from Luke Wroblewski.]

Here are some of the slides that Kevin used, created by the Happy Cog visual designers: Chris Cashdollar, Yesenia Perez Cruz, Brian Warren, and Kevin Sharon. Imagine presenting your own work, having to work these images into your description of why you made the choices you did. How fun is that?

This year was no exception, and one conversation that stood out was a quick discussion I had with Kim Goodwin, author of Designing in the Digital Age and who gave her workshop on designing with scenarios. While we were talking, we got on the topic of what questions designers need to know to create great designs.

Kim’s thinking is there are only five questions that are essential to creating great designs:

1. What is the user trying to accomplish?
2. What does the user need to know to accomplish their goal?
3. How should the user feel as they accomplish it?
4. How does the current design (or alternative) currently make them feel?
5. What did they do to accomplish it?

She boils it down to three essential components: Accomplish, Know, and Feel. If you understand what your user wants to accomplish, what they need to know, and how they want to feel, you’re well on your way discovering what’s necessary for your design to be great.

It’s not too different in our world of design. There’s a lot of long-forgotten “old thinking” which is relevant with today’s thinking. In today’s article, I share an old model that has appeared on my radar over the last few years.

If you hang out with me, you’ve probably heard me say, “Good judgment comes from experience, and experience comes from bad judgments.” Today’s article describes a model that explains how that maxim actually works. The model is called The Four Stages of Competence, and has a myriad of uses in our design work.

Read the article: The Flexibility of the Four Stages of Competence.

What old thinking have you discovered lately? How do these four stages fit into your design work? We’d love to hear your thoughts below.

However, where I think Mr. Gruber gets it wrong is the value to the internal design team. The Apple Knowledge Navigator created a ton of discussion internally and set the company off on a 23-year journey that now brings us some amazing technology, which was impossible to imagine back in 1987 when the video first came out.

When an experience vision, like the Knowledge Navigator video, works, it gives the teams a chance to ask the question, “Am I getting closer to that design?” with every decision they make. It helps the team, as a whole, understand where it’s trying to go.

When teams don’t have a vision like that, each person is walking around with a different understanding of what the end of the journey should look like. When there’s no common understanding on what that end point looks like, each decisions is evaluated on a different criteria and the resulting products end up looking like crap.

I think the Microsoft and RIM videos are interesting. However, there’s too much in there. Apple’s Knowledge Navigator was simple in its delivery, covering only a few concepts. There are so many concepts in each of these new videos that I find it hard to believe the design teams can talk about what they are really trying to say.

I’m also betting that Microsoft and RIM have made classic mistakes: the visions represented in these videos are not put together by the teams that will be working towards them. They were likely created by marketing folks (and, even more likely, by outside agencies with no connection to the internal product development and design teams). It’s possible that the developers and designers at these companies saw the videos at the same time we did.

Unless the design and development teams have a voice in what their future is, they are unlikely to buy into it and will probably take their designs in a different direction. Team collaboration on the vision is critical for success.

I don’t think these visions need to be publicized to be useful. And, as Mr. Gruber asserts, it’s brings into focus the failings of the current products when they do.

However, there is real gold in having a solid vision and these videos can be a great way to represent that vision within the organization.

However, if we didn’t make proper arrangements before we took the job, it’s very likely we can’t show much of our work to anyone. Consultants, contractors, and full-time employees are usually covered (in the US at least, but most other places as well) by a “work for hire” agreement, which means that the people we work for own all the work product we produce.

Wireframes, sketches, and other deliverables are not ours to show. If the final design isn’t publicly visible, such as internal application, there might not be any evidence of what we’ve done.

This puts us in an uncomfortable position when it comes time to show our work to a prospective employer. How do we show what we’re capable of when we don’t have access to our work?

Some have advised that you can put your company’s work files into a “for your eyes only” confidential portfolio, asking the hiring manager to keep what they see a secret. While it’s unlikely you’ll get caught doing this, does it send the message you want to someone thinking about hiring you? After all, it could be interpreted that you don’t take company policies, like confidentiality, seriously and that may not be a great first impression.

Fortunately, a smart hiring manager should understand this dilemma well. They’ve seen others with it and probably have faced it themselves when they interviewed at the company. Those smart hiring managers will look for other evidence of your talents and skills.

What can you put into your portfolio when your work is all locked up?

The simple answer: Fill your portfolio with stories.

When we’ve talked to the hiring managers behind some of the best design teams, we’ve seen that they are less interested in the final products and more interested in how the candidate got to those products. They’re interested in the story behind each design more than the designs themselves.

A good hiring manager wants to hear what the project goals were. They want to hear what you were given to start with. They want to hear the major challenges you faced, and how you overcame them. They’re interested in who else was on the project and how well you worked together. They want to hear about that guy who was always in the way and what you did to work around his objections and obstacles.

A great design portfolio tells the story about your designs, even if it can’t really say much about the design’s specifics.

To prove you know what the work products are, you can fake those. You can create wireframes, sketches, and other deliverables for side projects. In addition, you can mockup what your work would’ve looked like, without giving away the details that your employer wants to keep secret.

But the best designers talk about their journey. And the ones with the best stories are the ones that get hired. Especially when the new job is filled with exciting adventures.

That’s what the legal secretary told me when we were studying her firm’s intranet home page. In fact, the page was pretty sparse in layout. The text was nicely laid out in a readable font, with different weights given to headings and body text. Overall, it was organized and readable. Cluttered just didn’t seem like the right word.

Yet, the legal secretary was quite firm on this. She wasn’t the only one. Half of the firm’s employees we interviewed used the word “clutter” to describe the page that looked anything but cluttered to us.

It might be tempting to rework this home page with more whitespace, more organization, more emphasis on the visual design. However, that wouldn’t have produced any better results.

Over the years, we’ve learned that users have a different meaning of “clutter” than the designers do. It’s not the visual design the users are reacting to. It’s the actual content.

The law firm employees were telling us that the page didn’t have links and resources they needed. The page was full of stuff — mostly things the firm’s marketing group wanted everyone to know — but very little of what was on the page helped the employees do their jobs. Everything they needed was on the intranet, and they knew it, but the home page didn’t lead them to it.

The page was cluttered.

Clutter is what happens when we fill a page with things the user doesn’t care about. Replace the useless stuff with links, copy, and content the users really want, and the page suddenly becomes uncluttered.

Dictionary.com’s definition of Clutter is found on a page, ironically, filled with clutter.

That’s exactly what we did at the law firm. Our design team uncovered those resources the users needed and organized the page to have exactly what the users needed to do their jobs well.

Those users loved the new page. In our evaluations, nobody used the word clutter. They used words like useful, helpful, and awesome.

Here’s the best part: We put the old and new pages side-by-side. The new page definitely had more text, less whitespace, and more dense information design. Yet, when we asked the users to tell us which one was more cluttered, they were unamimous: the old design was the cluttered design.

Are your users complaining about clutter? Maybe you should look at what they actually are seeing.

One cause is that we tend to think of complexity as a holistic effect. We try to decide if the entire design is complex or not. However, it’s easier to realize where your design is baffling your users if you hone in on what your users do and don’t know, and what they need to know to accomplish their objective.

In today’s UIEtips, I explore a simple visualization tool we invented to help teams and stakeholders see where their designs are too complex for their users and what they can do about it. I call this tool the Magic Escalator of Acquired Knowledge and, as you’ll see, it can be quite effective for getting the entire team working on making an easier-to-use design.

Read the article, Riding the Magic Escalator of Acquired Knowledge.

Now, these are often implemented with a checkbox that says something like “I have read and agree to the terms and conditions.” Most of us know that hardly anybody reads and everybody just checks off the box. (Once, I watched my dad, a lawyer, check the box without reading. “It’s probably unenforceable,” he told me.)

But on this new Amex site, there’s a different implementation of this control. Sure, there’s a checkbox, but it’s grayed out. The only way to enable it for checking is to scroll to the bottom of the agreement.

The Amex Biz Travel site greys out the checkbox until the user scrolls to the bottom.

Now, as is also standard, the agreement is presented in a tiny little scrolling text box that shows about 200 words at a time. And, as is also standard, the agreement is a whopping 7,243 words (13 pages in a standard document) long.

Therefore, scrolling through this box takes a fair amount of effort. It’s unlikely that scrolling will encourage anyone to read the document. It’s just an extra hoop to jump through to continue the farce of pretending that the user has “read” whatever it is their agreeing to.

Apparently, the lawyers at Amex think that by having me scroll to the bottom, they can claim that I had every opportunity to read and agree to the terms. Therefore, if there’s something down the road I want to sue them about, I gave up that right with my scrolling action. (It’s unlikely any sensible judge will buy this argument, but it’s just as unlikely that any suit against them will get in front of a judge.)

Of course, the best way to do this would be to be honest with your users and treat them with respect. Amex could write the terms in simple language and give users a chance to really understand what they are agreeing to.

The problem with a design solution like the “scroll to agree” implementation is that it won’t be good enough. What happens when some other lawyer at Amex (or whereever) discovers that users don’t read it when they scroll to the bottom and therefore don’t understand what they are agreeing to? They’ll put in some other ridiculous control, where you’ll have to enter a secret code or recite poetry or something.

At some point, we, as designers, have to stand up and say, “This isn’t really doing what you think it’s doing. It’s just making our relationship with our users worse.” When do we do that?

I’d like to start now.

Now, if we’re building enterprise accounting software, why do we need to know whether Mary has a schnauzer or Wilbur drives a Hummer? There’s nothing those details will help us in the design.

Every detail in a persona description should help inform decisions in the design. Because of that detail, we should have no trouble saying what we’d do. When we’re working on accounting software, knowing they are a PC or a Mac user could be important. Knowing that our persona visits their customers and need up-to-the-minute inventory data on the road is likely to be critical. But what does it matter what car they drive?

I call this problem the “Dog and Hummer Trap.” It’s when the design teams takes their persona descriptions just a little too far.

However, this client team was different. They were designing a searchable database of home improvement projects.

Pets and cars, in fact, are important. The team wanted to have a way to identify “pet friendly” projects, where they provided special instructions for keeping safe from the hazards of construction.

They also wanted to help users figure out how they’ll get the materials home. A SUV carries more than an Mini Cooper, so the make of car matters.

The Dog and Hummer Trap isn’t specifically about dogs and cars. It’s about making sure you’re focusing on those details that’ll make a difference in the design.

But that’s different than a critical exploration of what we’re trying to do. Where we learn what it takes to make a great design. Where we explore both the problem space and the possible design solutions.

I ask teams whether they do critiques. “Oh, yes. All the time,” they tell me.

However, when I ask them what it is they do, it’s basically a meeting where someone’s work is criticized for what it’s missing. It’s a meeting where people who haven’t given the design problem or solution much thought, until that moment, rip apart the work of someone who has.

These critical design reviews are miserable experiences. Everyone completely dreads them. The experience makes them feel like crap. And then it’s time to schedule another one.

I’ve been working with teams to change that. We’ve taken the traditional studio critique process and brought it into the modern world.

What makes a critique different from a critical design review is we are not there to find flaws. We’re there to learn from the design and to explore where it works well and where it could be improved.

In a well-run critique, we explicitly separate out the discussion of “What are we trying to do with this design?” from the discussion of “Does this rendition accomplish it?” By separating out these two pieces, we avoid digging into the designer’s work just because they unaware of a critical requirement or need.

The critique technique we use has a structure. First, we start each session with a brief introduction to the technique, for all those folks who are participating for the first time.

Then the designer describes what they were trying to accomplish with their design. What was the problem? What were the priorities they took under consideration? What did they bring from what they learned in previous critiques?

If everyone in the room agrees, we can move on. However, if someone thinks we’re solving the wrong problem or that we didn’t take the right priorities into account, now’s the time to speak up and discuss it. (Ideally, we would’ve discussed these things before the designer put the hard work into the design iteration.)

Then the designer shows us what they’ve done. They specifically talk to what the design is trying to do, telling us what they were thinking and how they solved the important problems. The goal is to not only show us the final design product, but to give us the thinking behind it, opening up their rationale.

After the designer has shown everyone what they did and why they did it, everyone starts with what they liked. After all, there’s something to like in any designer’s work.

Pointing out the likes isn’t just an exercise to be nice and respectful. It helps everyone understand the qualities that are desirable. (This is one place where criticism-focused design reviews often fail miserably.)

The audience also now can explore the design. Often this is done, not with critical commentary, but with exploratory questions. “Have you thought about how users will share the photos with their friends?” “Have you considered how the application works when there’s no network connectivity?”

By posing their thoughts as questions, the designer can say whether they’d thought about that issue or not. If they have, it gives them a nice chance to talk about their thinking. If they haven’t, well, they just say, “No, hadn’t thought about that yet.”

Of course, we record all the things that come up — what people liked and what questions they had. At the end of the session, we review them, to make sure we’ve captured everyone’s thoughts.

While we avoid group design in these sessions, we do encourage conversation that helps us explore what we’re trying to do. The designer takes what they heard and integrates it into their next iteration, presenting it at the next critique.

Team using this process tell us they get a ton more out of each session, enjoying the process of learning about their designs. It also doesn’t hurt that the designs they’re producing show a marked improvement.

But something is still missing. Though we are making progress and laying groundwork in large organizations, many UX teams still struggle with getting the necessary time and resources to do their jobs as effectively as possible. To continue growing our profession in both influence and in number of good designers, we need to find a sense of leadership.

In today’s UIEtips, we’re reprinting a fabulous UX Magazine article by one of our favorite people, Kim Goodwin. The difference between management and leadership is a great one. Kim believes that UX leadership should contain things such as mentoring and providing vision. Leadership itself is a skill that should be grown along with UX expertise.

Read the article, On UX Leadership.

In addition to her full-day workshop at User Interface 16, Kim will be giving a 90-minute talk, Experience Leadership. Kim will explore how we develop a broad view of what a UX leader is and how we develop both practice leadership and change leadership skills. Join us for UI16, November 7-9 in Boston. You won’t want to miss it!

That’s not the case when you bring Adapative Path’s CEO, Brandon Schauer into the picture. Brandon has a way of getting an entire team—executives, designers, developers, marketers all producing dozens and dozens of ideas. He does this through a group of excerises and tools you’ll find in a workshop called Good Design Faster.

In today’s article, we look at an excerpt from an interview I had with Brandon back in September. Brandon shares his methods on how to get your team producing many ideas, what makes ideas tangible, and why it’s critical to move past the first idea.

Read the article, Good Design Faster – An Interview with Brandon Schauer.

This article is just a small taste of what the Good Design Faster workshop is all about. On Wednesday, November 9, Brandon will share a lot more on Good Design Faster at an all day workshop at the User Interface 16 Conference in Boston.

How do you motivate your team to get innovative? Share you thoughts below.

We had been working on a client project, helping their team redesign their checkout process with some new user research and design techniques.

As we were watching seasoned shoppers buy products in the lab, we noticed that people were getting stuck at a screen right before the checkout process, where they had to authenticate their account. Repeat customers couldn’t remember their user ID and password combination. The site used an email address as the user ID, but many of our repeat customers had set up their accounts years before and couldn’t remember which of their email addresses was the ID.

In the lab, the customers who couldn’t authenticate would either give up or request a password reset. However, the password reset required they remember which email address was their ID, which many couldn’t do. We witnessed a remarkable number of abandonments on the password reset screen.

When the password reset was successful, the customer had to go to their email client, find the reset message (often lost in a spam folder), and click on a link in the email. In the lab, we observed that this was a complex process.

All of this led us to ask if this was only happening in the artificial environment of the lab, because we watching users in our space, not using their own machine. We set out to look at the site’s analytics to see if there were clues to this behavior happening in the real world.

The first thing we asked the analytics team was what percentage of visitors to the authentication page ended up on the reset password request screen. Turns out, they had never instrumented either page. We had to wait three weeks while they instrumented it and we collected a reasonable sample size.

We learned a substantial percentage of customers were requesting password reset, approximately 40%. Two out of every five users was getting stuck and needing their password to be reset.

We then wondered what percentage of those people actually came back to finish the transaction after the reset. Again, we discovered the analytics team hadn’t instrumented the return from the reset. That was another three week delay.

We learned that fewer than 25% of the resets were executed — the user clicked on the reset link and returned to the site. Of those who did execute it, fewer than 20% finished their purchases.

A little math and we could calculate out the amount of revenue being abandoned in the carts by all the people who couldn’t authenticate. That’s where the $300,000,000/year number came from.

Once the team implemented a guest purchase capability (which didn’t require authentication to start the checkout sequence), they saw an immediate jump in sales increase of about $6,000,000 in the first week, which remained constant. Password reset requests dropped by about 80% in that first week and remained constant too.

Authentication pages are usually owned by a different group in the company. In this case, they were owned by IT. IT didn’t have the foresight to instrument these pages.

Until we did this research and asked these questions, nobody knew how many people were dropping off at authentication. Because authentication was between the shopping-cart and the Enter-your-shipping-info pages, everyone thought they were getting a much lower percentage of users clicking the Checkout button than they really were. The site had a huge abandonment on authentication that heretofore had gone undetected.

Analytics only work when we know that they are measuring everything correctly. Working with clients, we regularly discover they aren’t capturing the entire picture, leaving out critical information.

Everyday, more companies are recognizing the value of design. They are realizing they need to have strong design to compete in the marketplace. They see their competitors, even the small ones that don’t offer as full a feature set, are eating away marketshare because they have better designed products.

No place manifests this more than Silicon Valley. Designers, especially good ones, can call their shots there. Companies are in a bidding war for talent.

That means, if you’re a good designer, you have to ask yourself: are you in the right place, right now?

Milton Glaser gave a speech a few years back. He talked about two types of relationships: those that energize and those that exhaust. Milton said he learned, the hard way, that he needed to regularly prune away those relationships that exhaust, focusing on the ones that energize. That was his advice to happiness.

If you’re a good designer, are you in a place where your work energizes you? Or does the organization you work for exhaust you, because it hasn’t realized how important design is to its own success?

Now, it’s not that every day will be free of frustration. But if you’re regularly energized, it’s much easier to face the tough challenges. When you’re exhausted by your work every day, the challenges often feel insurmountable.

When a company doesn’t get the importance of design, it’s rough being a designer there. You constantly have to explain what you do. You have to fight for the simplest things, like the time and resources to do research (and often fail). You see, everyday, how your work could be so much better if you had the right tools, the right support, and enough time to make it work.

It’s scary to think about change. But right now, the timing is right for designers. If the job you’re in isn’t the right one, you owe it to yourself to look at what your options could be.

If you decide you should explore the world of opportunities, think about what you’d want in your next job. A company that values design will push off a ship date because the product’s not well enough designed. Ask if the company has ever done that — that demonstrates whether they have their priorities aligned with yours. Delaying a launch is a hard call. Having done it means they are serious.

Look for other evidence they understand design. Do they take the time to do research? Is everyone in the team involved? Do they iterate frequently? Are they learning good things from each iteration?

These are the signs that a company wants to learn what the best designs are. That yearning to learn makes the workplace really exciting for designers who are innately curious and autodidactic.

It’s a good time to be a designer. Every day should energize you. Are you doing everything you can to make sure that happens? After all, you owe it to yourself.

I remember always being impressed with the pictures and talking about the Colosseum and the Roman Forum. Yet nothing could prepare me for my first trip to Rome. It wasn’t anything like the pictures.

I think this is exactly the same feeling that designers have when they visit their users for the first time. Sure, they’ve heard about users and what they’re like through the various sales and support channels. Maybe they even met one or two in their travels.

But seeing your users really work with the design is a whole different world. It changes the way you work and think about what you’re building.

In today’s UIEtips, I explain why I love taking teams out on their first site visits. It’s really exciting to see the transformation the designers undergo as they open up a new world. The metamorphosis they go through is really fun and exciting.

Read the article Why I Love Taking Teams On Field Visits.

If you’ve always wanted to go on your own field visits, you’ll want to get the best techniques from Steve Portigal, who is a master at these things. His User Interface 16 Conference full-day workshop will be a ton of fun. You’ll go on your own site visit and analyze the results – an amazing education. Check out how much fun it’ll be.

I asked (on the Twitters, of course) what was the first application to use the pull-to-refresh gesture. My world of followers suggested it was the original Tweetie app, which was then acquired by the Twitter overlords. Since Tweetie, it’s shown up in a bunch of apps on my iPhone. I’m told it’s also on apps all over those Android phones that everyone talks about.

What’s interesting about the pull-to-refresh gesture is how natural it feels. Need more stuff, pull down on the list. Very simple. Very intuitive.

Well, it’s only intuitive if you know about it. You see, the problem is the gesture has no affordance (a hint or clue that the function exists). There’s no way to know where pull-to-refresh is implemented. Anyone who has learned the gesture has probably experienced the pull-to-do-nothing function in all the apps where it’s not implemented. Suddenly, something that’s novel has become a basic expectation, just like Kano taught us it would.

If you didn’t know about pull-to-refresh, how would you learn it’s in your app? For the most point, it requires you learn it from someone else.

Someone who leans over and says, “Hey, did you know you can update your list by just pulling down on your thumb?”

“No Way!” is the usual response, followed by the now-common thumb maneuver. “Cool!” is what comes next.

And it happens. Just like that. We’ve just transmitted the functionality, socially.

Pull-to-refresh isn’t the only socially-transmitted functionality. In years past, it’s how I’ve seen people learn about drag-and-drop in applications. It’s how they learn about special keys, like F5 for refresh or F1 for help. A lot of functionality has been transmitted from one person to the next, socially.

There’s nothing wrong with socially-transmitted functionality, as long as it’s not something the user needs (they can use the design just fine without it) and you have users that talk with each other. The problem comes from when you, as a designer, know about an functionality that only transmits socially, it’s hard to realize that people around you haven’t caught on yet. Just because it’s in your pattern library doesn’t mean your users will know about it.

[A note about accessibility: socially-transmitted functionality is rarely accessible in itself, as it usually has no way for a screen reader to work. For accessibility reasons, you probably want alternative access.]

In a recent site visit, I watched users struggle with navigating around a web app because the return-to-main-menu function was a not-obvious icon that looked like decoration to the untrained eye. All the developers observing the visit knew about it, but this collection of users hadn’t been infected with the knowledge of the functionality, and therefore didn’t use it. Their alternative: sign out of the app and back in again, which returned them to the top-level menu. (Boy, did that ever elicit a sigh of wonderment from the observation party!)

Do you have socially-transmitted functionality in your design? Are they things that users can live without and will be delighted when they hear about it from a friend?

She’s been a designer for a long while now, having worked on some impressive projects and developed real skills. As she described the different projects, I could tell, however, that something was missing: how would she grow?

Don’t get me wrong. Each project was pretty neat and jam-packed full of cool challenges that every talented designer would want to sink their teeth into.

I suggested she direct her search in a different direction. I told her to focus on who her next manager should be.

In my job, I get to meet a lot of great designers, some of whom are working on projects that, to an outsider, might be considered dull: accounting applications, chemical analysis equipment, and even tax forms. Yet, they love their work, not because of the subject matter of the project, but because they have a great manager that makes every day fun and challenging (in the good way).

I’ve also met designers who are working on some of today’s sexiest design problems — working with the latest technologies on cutting edge, high visibility, society-changing designs. And they’re miserable because they have a manager that makes each day hard and frustrating.

When you have a great manager, the project barely matters. And when you have a crappy manager, the project barely matters.

The advice I’m giving to senior, more experienced folks is not to think about their next project as much as they think about their next manager. What traits should that manager have? How do they support their team? When things get rough, how do they deliver guidance? Do they regularly give out praise? Do they take a deep interest in the work and in their employee’s future?

I recommend folks interview the entire team and learn what it’s like to work for that manager. What happens when the going gets tough? What examples are there of team members growing, learning, and getting encouragement? Do team members talk about how the manager exhibits the desired traits?

My good friend, Amy Jackson, who works as a talent agent for wünderkind UX designers, suggests you take it a step further and ask the hiring manager for his or her references. Amy says to tell them you want to make the right decision and you need to check them out. Her thinking is that if the hiring manager isn’t secure enough give out sound references, they may be sending a signal. I think there’s something to that.

Great managers are what make a job great. Are you thinking about what you’d like to see in your next manager?

Right now, few things are hotter topics that mobile in the design world. With the burst of smartphone and tablet technology, the mobile design landscape has just exploded.

With this new landscape comes a new way of thinking about design. It’s no longer about filling every pixel on the screen and implementing a multitude of different functionality.

The smaller screen demands that we hone our functionality down to it’s bare essentials. It means letting the content drive what we do, instead of putting the actions first. And it requires we rethink the basics of interaction, as touch gestures offer more flexibility than the mouse pointer.

Nobody has thought more about what it means to design for mobile that Luke Wroblewski. For the past few years, he’s been touring the world with a detailed explanation of what it takes do create great mobile experiences.

We’re really excited that he’s joining us for UI16. If you think mobile is in your future, you need to make sure you attend his full-day workshop. There you’ll learn everything there is to know about making a fabulous, interactive mobile web experience.

Even though every designer we talked with had completely different backgrounds, training, and work habits, they all shared one common element—they sketched their work. In addition, they weren’t just sketching their designs. They were sketching their notes in meetings, their conversations with their co-workers, and their understanding of their design research. Sketching was a common medium for a variety of design-related activities.

In this issue of UIEtips, we look back at an article from a year ago. We take a tour of the different activities and the sketches we saw during our research. These sketches solve a multitude of important design problems and are key to becoming a design master. I’m sure you’ll find this as interesting as I do.

Read the article, Why We Sketch.

One of the most popular workshops at last year’s User Interface Conference was Good Design Faster. The workshop had a strong sketching component. Once again we’re offering this workshop, taught by one of its original creators, Brandon Schauer. On November 9 at the User Interface 16 Conference, Brandon will show you how to bring out innovative design ideas in record time. Explore Brandon’s workshop and the 7 other fantastic workshops at UICONF.com.

How do you use sketching in your work? Is this something new or something you’ve been doing for a while? We’d love to hear about your experiences below.

Back in 1987, Apple (under the direction of John Sculley, not Steve Jobs), released a video of what Apple products could be like in the future. Called the Knowledge Navigator, it showed a sci-fi mythical tablet computer from 23 years in the future (yup, 2010) that the user talks with to get things done.

Fast forward 24 years and Apple releases Siri with the new iPhone 4S. Siri is an assistant that takes voice commands and acts on them. If you haven’t seen Siri, here’s a demo.

Now, as far as I know, Siri is only available on the iPhone 4S. However, that’s likely temporary, as I don’t believe there’s anything that prevents it from showing up on other platforms, like the iPad.

And once it shows up on the iPad, Apple will have fulfilled it’s 1987 quest. All the components of the original Knowledge Navigator are now available and for less than $500.

In ’87 — when we all used big, boxy CRTs on bulky, loud, slow desktop processors without any notion of communications beyond 9,600 baud (14.4 came in 1991) — there was no way you could have a small, tablet computer to do all the things in that video. Knowledge Navigator was complete science fiction to everyone at that point. Computers couldn’t speak. You couldn’t imagine face-to-face video conferencing across the planet, let alone collaborative workspaces. None of that had been invented yet, except as sci fi.

Yet, if we look close, it’s the path Apple has been on for 24 years. We’ve seen the baby steps. With the introduction of the Mac Book, then the iPhone, followed by the iPad, we got our table. The interwebs provided the connectivity, where Apple focused on its Airport wireless products to get the components tiny. Innovations like built-in cameras and Facetime made the video conferencing a reality.

And now Siri completes the journey. Siri isn’t quite the bow-tied dude who can order a cake for your mother’s birthday party, but it’s damn close. (And I’m not convinced we need avatars to believe the computer is speaking. I think Second-Life ruined avatars for everyone, except those who enjoy online virtual sex.)

In 1987, when Apple first released the video, they received a fax (!) with a purchase order for the Knowledge Navigator. Now they can finally fill the order.

I’ve seen my share of really great designs. However, I’ve also seen many bad designs.

Yet, interestingly enough, I’ve never met anyone who wanted to make a bad design. Nobody said to me, “I’m trying to build the suckiest design out there. Something people will really hate.”

Behind every bad design was a team that wanted to do the right thing. They wanted to make their designs a success. It just didn’t work out that way.

Almost always, it was because something was missing. The designers didn’t know what it would take to get a great design.

Often, they thought they knew. They thought they had the right mix of savvy and intuition to make it work.

Good design, it turns out, is harder than just being a smart guy. You have to know who your users are. You have to know what your users need. You have to know what your technology can and can’t do. You have to know what will truly delight the people you’re designing for.

It goes beyond just knowing stuff. You also need to do stuff and do it well. You have to draw on the language of interaction. You have to experiment and prototype. You have to interpret the feedback you receive and adjust your thinking.

What the folks creating bad designs are missing is good knowledge and skills. Without these, they produce crappy designs.

The good news is we now know, thanks to a ton of research in recent years, what much of the knowledge and skills are. We know how to take designers who regularly produce bad designs and turn them into designers who produce good designs, and eventually, great designs.

It’s a great era to be a designer. There’s so much to learn. There’s so much to do.

Our goal, of course, is to learn everything we can. We need to leverage the research time to ensure we’re filling our brains with the information. Then we’ll need to create great designs.

In today’s UIEtips, I look back at an article from last year. I talk about three questions I’ve learned not to ask in sessions. By avoiding these questions, we get to the information we need faster.

Read the article, 3 Questions You Shouldn’t Ask During User Research.

Dive deeper into user research with Steve Portigal’s workshop Immersive Field Research Techniques at the User Interface 16 Conference, November 7-9, 2011. Steve will show you simple and effective field techniques for a deeper look at your users.

And once you’ve learned what you need from your research, you’ll want to put it in a format that helps you speed through your design process. That’s exactly what scenarios help you do and, coincidentally, why we’ve asked Kim Goodwin to return to this year’s User Interface 16 Conference to repeat her popular workshop on Designing with Scenarios. She’ll teach us how to make scenarios work.

You can find out about Kim, Steve, and the other great UI16 experts at UICONF.com.

Have you compiled your own questions that you shouldn’t ask? Share your list below.

I don’t decide to leave out the baking soda (even though I don’t really know what the baking soda does). Nor do I decide to cut the sugar in half (even though I think lots of sugar is probably bad for me). Why? Because if I did those things, the cake wouldn’t come out well.

This is exactly what we see teams do with their persona and scenario projects.

We see a lot of teams trying to create them. Building out solid personas is a great way to create innovative user experiences, when done well. Yet, many teams choose to sabotage their persona projects, producing something that doesn’t do the job and wastes valuable resources.

There are many recipes for great personas, yet the teams decide to take shortcut, skip steps, or just plain do something that doesn’t make sense. They don’t follow the recipe. Then they complain when the project doesn’t turn out well. And they lose the value that comes from a well-executed persona project.

In this today’s UIEtips, we explore five ways that teams we’ve studied sucked the value away from their persona projects. They seem like obvious things to do right, yet these teams opted to go another way, and then didn’t see the value they were hoping for.

Read the article, 5 Ways To Suck Value Away From Your Persona Projects.

At the User Interface 16 Conference, we’ll be exploring ways to get the most from your design projects, including persona techniques. Kim Goodwin will show us how to get huge value from creating great scenarios to drive our designs. And Steve Portigal will show us how to use field research to uncover insights and produce solid innovations. Check out UI16.

A few weeks ago I interviewed Stephanie (Sullivan) Rewis and Greg Rewis to find out what they’ll cover in their UI16 workshop, Everything a Designer Needs to Know About CSS3 and HTML5. Let me tell you, there’s a lot.

In this article, we explore why rounded corners and drop shadows are such a big deal for both the designer and the SEO specialist. Then we take a look at what a media query is. Finally, we wrap up with why Stephanie and other designers are having a love affair with Modernizr. The podcast covered even more material so you may want to give it a listen or read the transcript.

Read today’s article: A Snapshot on What Designers Need to Know about HTML5 and CSS3

Whether your learning about these new benefits now or are already familiar with them, but don’t know how to put them into action, you’re in luck. Thursday, September 15, Stephanie is giving a 90-minute virtual seminar on how to implement many of the new CSS3 features. You won’t just hear about the benefits, you’ll learn the coding behind it. Think of it as a teaser to Stephanie and Greg’s full-day workshop at the User Interface 16 conference where they’ll dive even deeper showing you how to put HTML5 and CSS3′s new features into practice.

Back in the early days of PC computing, we were interested in how people used all those options, controls, and settings that software designers put into their applications. How much do users customize their applications?

We embarked on a little experiment. We asked a ton of people to send us their settings file for Microsoft Word. At the time, MS Word stored all the settings in a file named something like config.ini, so we asked people to locate that file on their hard disk and email it to us. Several hundred folks did just that.

We then wrote a program to analyze the files, counting up how many people had changed the 150+ settings in the applications and which settings they had changed.

What we found was really interesting. Less than 5% of the users we surveyed had changed any settings at all. More than 95% had kept the settings in the exact configuration that the program installed in.

This was particularly curious because some of the program’s defaults were notable. For example, the program had a feature that would automatically save your work as edited a document, to prevent losing anything in case of a system or program failure. In the default settings for the version we analyzed, this feature was disabled. Users had to explicitly turn it on to make it work.

Of course, this mean that 95% of the users were running with autosave turned off. When we interviewed a sample of them, they all told us the same thing: They assumed Microsoft had delivered it turned off for a reason, therefore who were they to set it otherwise. “Microsoft must know what they are doing,” several of the participants told us.

We thought about that and wondered what the rationale was for keeping such an important feature turned off. We thought that maybe they were concerned about people running off floppies or those who had slow or small disks. Autosave does have performance implications, so maybe they were optimizing the behavior for the worst case, assuming that users who had the luxury to use the feature would turn it on.

We had friends in the Microsoft Office group, so we asked them about the choice of delivering the feature disabled. We explained our hypothesis about optimizing for performance. They asked around and told us our hypothesis was incorrect.

It turns out the reason the feature was disabled in that release was not because they had thought about the user’s needs. Instead, it was because a programmer had made a decision to initialize the config.ini file with all zeroes. Making a file filled with zeroes is a quick little program, so that’s what he wrote, assuming that, at some point later, someone would tell him what the “real defaults” should be. Nobody ever got around to telling him.

Since zero in binary means off, the autosave setting, along with a lot of other settings, were automatically disabled. The users’ assumption that Microsoft had given this careful consideration turned out not to be the case.

We also asked our participants for background information, like age and occupation, to see if that made a difference. It didn’t, except one category of people who almost always changed their settings: programmers and designers. They often had changed more than 40% (and some had changed as much as 80%) of the options in the program.

It seems programmers and designers like to customize their environment. Who would’ve guessed? Could that be why they chose their profession?

(Big takeaway: If you’re a programmer or designer, then you’re not like most people. Just because you change your settings in apps you use doesn’t mean that your users will, unless they are also programmers and designers.)

We’ve repeated this experiment in various forms over the years. We’ve found it to be consistently true: users rarely change their settings.

If your application has settings, have you looked to see what your users do? How many have changed them? Are the defaults the optimal choice? Does your settings screen explain the implications of each setting and give your users a good reason for mucking with the defaults?

Back at the end of June, Dan Rubin presented a UIE Virtual Seminar, CSS3 for Everyone. Because there were so many questions we didn’t get to during the webinar, Adam Churchill and Dan recorded a follow up podcast.

In today’s UIEtips article, we look at 2 sections from the podcast: how to use CSS3 when designing for mobile, and what CSS tools and resources Dan relies on to save time and make designing easier.

Read the article: CSS3 – Tools and Mobile Implementation

Dan is a highly accomplished user interface designer and usability consultant. If you missed his virtual seminar, you can still access the recording in our User Experience Training Library access it.

And if you’re looking for more tips and tricks with CSS3, you’ll want to sign up for Stephanie (Sullivan) Rewis’s webinar on September 15. Stephanie is a prominent front-end developer, corporate trainer, noted champion of web standards, and an excellent speaker. Learn more about her virtual seminar.

In Agile, these contributions and expectations aren’t nearly as clear. Waterfall gave us nice “hooks” to hang our UX work on, but Agile doesn’t do that. The team breaks up work into small chunks and just starts chipping away at it. There’s no clear point when requirements are done (they are gathered in parallel with trying out the designs). There’s no clear point when design is done (it evolves over the duration versus being declared up front). It doesn’t seem that there are any clear hooks in an Agile process.

Interestingly, if you dig deeper, the hooks are there. In this issue of UIEtips, we’re revisiting the conclusion to Jeff Patton’s two-part article on his best practices for integrating user experience work into an Agile development environment. He talks about how teams he’s worked with have found the hooks and made it work.

Read the article 12 Best Practices for UX in an Agile Environment – Part 2.

Jeff is also presenting our next virtual seminar Story Mapping for UX Practitioners: Tying Agile & UX Together. If you work in an Agile environment and you’re struggling to weave UX thinking and principles into the iterative process, you’ll definitely want to attend this seminar. This seminar is on pace to sell out, so save your spot today.

The client was dealing with balancing a lot of navigation while keeping their home page free for the important messages they want everyone to see. A mega menu – those large multi-column layered menus that pop up when you hover over the navigation – seemed like just the ticket.

However, our research shows mega menus come at a price. In today’s UIEtips, I talk about the epic forces that are constantly in battle with any mega menu implementation, preventing the users from getting value. Every time I start talking about this stuff, designers perk right up. If you work on your site’s navigation, you’ll see why mega menus may not be the panacea they promise to be.

Read today’s article, 6 Epic Forces Battling Your Mega Menus

Of course, what we’re talking about here is just one type of web design pattern — exactly the topic Hagan Rivers is talking about at our upcoming User Interface 16 Conference. If you’re doing any design for the web, you’ll want to dive deep into her full-day topic. She’ll fill your brain with exactly what you’ll need to create delightful and useful online experiences. Check out all the UI16 speakers at UICONF.com.

The same can be true in an Agile development process. Often times, the team will start with a piece of the project that isn’t the first thing the user experiences, but instead might be at the end.

In this week’s UIEtips we are revisiting part one of an article we published by Jeff Patton in 2008 on his 12 Best Practices for UX in an Agile Environment. Jeff has been working with Agile teams and user experience professionals to discover the best methods to work together to create great results.

Jeff mentioned that user experience designers on the Agile team end up adopting a similar role to the person who gets the credit of “Continuity” in a film. It becomes their job to make sure the final experience makes sense, even though the order of construction was not linear. This is a huge challenge and one that has come to the forefront as more teams move to an Agile development method.

Read Jeff’s article 12 Best Practices for UX in an Agile Environment – Part 1.

Jeff is also presenting our next virtual seminar Story Mapping for UX Practitioners: Tying Agile & UX Together. If you work in an Agile environment and you’re struggling to weave UX thinking and principles into the iterative process, you’ll definitely want to attend this seminar.

In our experience, one of the most powerful ways to gather important insights about users is the field study. By making direct observations, design teams can identify opportunities they may have never discovered if they had only conducted usability tests, focus groups, or surveys.

I think it’s essential for all designers to really understand how to conduct a field study and learn how to gather critical information about users. That’s why in this week’s UIEtips we’re reprinting an article from 2007, where I discuss the unique power of field studies.

Read the article: Field Studies: The Best Tool to Discover User Needs

We are so excited about this topic that we’ve invited Steve Portigal, a world-renowned expert in ethnography and innovation, to conduct a full-day workshop at this year’s User Interface 16 Conference in Boston, November 7-9. If you’ve never done fieldwork, or want to learn the latest techniques for extracting brilliant design ideas from your customer visits, you’ll definitely want to explore Steve’s workshop at UICONF.com.

When you break it down, the elements behind content strategy, such as information architecture, copywriting, search engine optimization, and content management, are not new. But they’ve never been combined into a strategy before, where teams can plan and execute the necessary activities to keeping great content up-to-date and working for the user.

Over a year ago we featured our first virtual seminar on content strategy with Kristina Halvorson. Since then, a lot has happened in the field, including an entire conference, Confab, dedicated to content strategy. It was run by Kristina’s company, Brain Traffic. UIE lent a hand producing the conference.

We thought it was time to reprint an article that Kristina wrote from UIE’s vast article library. It’s a fabulous introduction to what content strategy is and how you can start to make it work for you. I know you’ll enjoy it.

Read the article, The Discipline of Content Strategy.

We’re thrilled to bring you another UIE Virtual Seminar that touches the content strategy field.Margot Bloomstein will present Combining Curation with Your Content Strategy, Thursday, August 11.
If you struggle with how to tackle your organization’s web content, this webinar is for you. Explore the webinar.

Outsourcing your user research work is like outsourcing your vacation.
It gets the job done, but probably won’t have the effects you were seeking.

I usually say this when someone is asking me to do their user research for them. This is something we did quite a bit in the early days of UIE, but don’t do any longer.

Usually, they are asking us to do this to save time, because they don’t have trained folks, or because they are afraid of bias. All these reasons are rational, but there are better ways to deal with them than hiring someone else to do the research on their behalf.

As I said, I founded UIE as a company to do just this. I felt the rational reasons where why companies weren’t conducting their own research. I thought we could offer cost-effective, inexpensive research services to help. User Interface Engineering, in 1988 (it was our 23rd birthday yesterday!), was one of the first companies to make user research services available to other companies.

However, after working with hundreds of teams and providing their research, we started to looking at how effective we were. Were the teams’ designs getting better? Were they doing more research? Were they creating better user experiences?

We were sorely disappointed with our results. While every team told us they really got a lot out of our work, most weren’t improving their designs. They were appreciative of our reports, but hadn’t read them. They enjoyed our presentations, but weren’t really adopting the recommendations. And, most importantly, their culture didn’t change — they weren’t integrating users into their design process any more than before.

It wasn’t only UIE’s clients with this problem. We reached out to organizations using other outsourced user research services and discovered the same results. Hiring the work out wasn’t getting the job done.

We realized that we were missing an important variable in user research: the team’s direct exposure to their users.

When we take a team on a field research project, we introduce the team members to their users and having them spend time seeing them use the product and doing their work. In doing this, we’ve accomplished 90% of the work of the project.

It’s the exposure that changes the way people work. The same is true for usability testing or interviewing users. The direct exposure is the most valuable part of the project.

When you hire out your user research, even to the most competent of user research professionals, you’re losing 90% of the value. The research becomes a game of telephone, where the “away team” (to steal a Star Trek term) learns all about the users and somehow has to communicate back what they’ve learned. No mount of report writing or presentations can replace that lost experience.

Some UX service companies will tell you that they’ll remain part of the team, integrating the knowledge they learned into the design as the project continues. However, that creates an imbalance, where some people on the team know the users well and others have no idea. Those others, who will eventually own the entire design, are working at a disadvantage and won’t be making their design decisions using this critical knowledge.

This is why we now refuse projects where the team wants to outsource their research. We still do plenty of field visits and usability tests with our clients, but only if they come along to every session. If the client team isn’t there, we won’t conduct the session – there’s no point.

For the folks that think they don’t have time to do their own research: You’re better off taking the money you’ll spend on hiring someone and burning it in the back yard. You’ll get the same value in your product.

Seriously, if you want someone else to do your research because you don’t have time, you’ll need to dedicate twice as much time to spend with the researchers, extracting every little thing they learned about your users. Otherwise, you won’t get the value you paid for. It’s not a time saver to go this route at all.

For the folks who feel they don’t have the skills onboard: That’s an easy problem to fix. Training on user research methods is pretty easy. This is the bulk of our consulting work these days. We use a “Watch one, Do one, Teach one” approach. (We stole it from the medical training world). Most teams pick up the skills pretty quick and do a damn good job in just a few weeks.

And for those folks who feel doing your own research introduces a bias: You’re right, but it doesn’t matter. There’s always a bias in research, even when you get a third party to execute it. There’s nothing wrong with biased research, as long as you understand your biases and how to counter act them.

If there’s anything you can outsource, it could be participant recruiting. However, make sure you work with someone trained in UX recruiting, not market research recruiting. UX trained folks (we use Usability Works – they’re awesome!) know how to deliver the information they learn about your users in the process.

That said, you should even try to resist outsourcing your participant recruiting. You learn a lot when you talk to your potential users, even if they don’t qualify for the study. When you’re outsourcing it, you’re flushing a lot of great source material down the toilet.

Once you’re in the habit of doing your own research, you’ll never want to go back. It’s just too awesomely addicting and useful.

More and more, we’re finding ourselves in situations where the design just “has to be right.” No longer, can we just have incremental feature enhancements or small improvements in the design. Our users need to be wow’d and delighted. And adding large fonts in bright colors with rounded corners will only take us so far.

To truly delight our users, we need to dig deep into what is meaningful and valuable to them. Give them something that resonates and they will jump for our design.

We can discover those resonance points by taking our research into the field. We meet the users in their own environments, observing them as they live their lives and do their work. We bring back oodles of data, which, once we analyze and synthesize, we can reveal the delightful essence of new designs.

Steve Portigal has traveled all over the world to do just that. He’s spent thousands of hours in people’s homes, offices, and the other places of their lives, just to learn more about what will delight them. His work with design teams has taught them to mine their rich data sources and uncover a wealth of value and meaning to design for.

Steve’s full-day workshop at UI16 will take you through the entire process. Prepare for a hard day of work, which starts with a real field visit. You’ll bring back observations that you’ll work with for the rest of the day. Under Steve’s expert guidance, you’ll learn the best methods for interviewing users, analyzing the data, and synthesizing the key meaning.

You’ll be ready to head right into the field the moment you get back to your office.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

Earlier this year, Kim presented a UIE Virtual Seminar, Designing with Scenarios: Putting Your Personas to Work. There were so many awesome questions, but we ran out of time for Kim to answer them. So Kim and Adam recorded a podcast addressing the unanswered questions.

Today’s UIEtips article is based on Adam and Kim’s podcast focusing on 2 questions: Do you need data to effectively do scenarios, and what’s the difference between scenarios and storyboarding?

Read the article Designing with Scenarios: Putting Your Personas to Work.

Kim Goodwin is our go to person when it comes to personas and scenarios. If you missed her virtual seminar, in May, you can still access it. And we’re very excited to have Kim back at the User Interface 16 Conferenceto give a full-day workshop on scenarios. Her workshop was one of the highest rated at last year’s conference. Explore Kim’s workshop and the other seven workshops offered UI16.

So much of a project’s success is determined at its start. If the team comes together and sets the stage properly, everything works out smoothly. People end up with a great vision and solid understanding of how the design should turn out.

Yet, a project that doesn’t get off to the right start will often struggle. The team will find themselves in conflict, important requirements often emerge too late, and good ideas get left on the cutting room floor. Unfortunately, in my work, I see too many projects that have gone down this road and find themselves trying hard to get back on track.

A few years back, I was lucky enough to see Kevin Hoffman present his workshop technique for kicking off projects. It was a completely different approach than any I’d seen before. He showed us how interactive exercises, brainstorming games, and collaborative sketching techniques surfaced important details about the project, while elliciting innovative ideas from everyone on the team.

Since then, he’s had the opportunity to refine his methods in his projects at Happy Cog, a leading web design firm. Happy Cog’s clients have been so impressed, they’ve asked him to teach them his techniques so they can kickoff their other projects successfully.

I’m really pleased that we can have Kevin as part of the User Interface 16 Conference program. As we’ve been working on the plans for his full-day workshop, I’ve gotten a glimpse of just how much fun this day will be. Kevin knows his stuff and has packed the day full of both solid theory and practical exercises. It’s almost criminal that something this fun is a critical work skill.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

These experts will dive deep and get to the nitty-gritty details that make any designer a UX pro. Look at the intensive full-day workshops we’re putting together for you.

• Brandon Schauer: Immerse your team in an innovative design process that produces refined design ideas in record time.
• Kevin Hoffman: Facilitate productive and insightful kickoff workshops to start your projects with everything you need.
• Hagan Rivers: Employ best practices to simplify your most complex applications with state-of-the-art UI techniques.
• Steve Portigal: Drive your design with effective field research to deliver innovative results.
• Bill Scott: Discover the latest rich interaction techniques for engaging user experiences.
• Kim Goodwin: Compose compelling stories that drive a realistic design process from start to finish.
• Stephanie Sullivan Rewis and Greg Rewis: Enhance your designs with HTML5 and CSS3 without sacrificing your design goals.
• Luke Wroblewski: Integrate mobile design’s best practices and techniques into your process.

Get more information on the workshop topics and speakers at UICONF.com.

Details on the Sneak Preview Site

In the next few weeks, more details about the agenda and workshop will emerge. However, you can get a view into our special sneak preview site now.

And because the site is in the sneak preview mode, we’re offering a sneak preview price – our lowest price, of $1,349.

On Wednesday, July 27 at 1:00 pm, registration will open.

There are 100 spots available at the special low price of $1,349. Once they are gone, they are gone and you’ll have to buy one of the more expensive spots.

There is a way to get a jump start on registration, and learn about exclusive offers and the latest UI16 news. Add your email to the UI16 list at UICONF.com and you’ll automatically get added to the priority group.

Now go see the 8 different design workshops we have in store for you at UICONF.com.

What happens over time with applications is a design entropy sets in. As new features are added, they are glued on top of old ones, often with slightly different interfaces. Slowly, the application starts to develop a Frankenstein look-and-feel, which hurts the users and the business.

Teams can avoid all this. Using established, well thought out, and proven user interface design patterns, teams can hedge these problems off before they become unmanageable. Even the worst applications can benefit from the careful hand of applying the best design practices.

There’s no one who knows how to deal with hedging off design entropy than Hagan Rivers. I first met Hagan back in 1995, when she was working for Netscape as one of the world’s first web application designers. Since then, she’s become a world expert in interface design, helping hundreds of teams get their application UIs under control.

I’ve had several opportunities to work with Hagan on various projects. Each time, I walk away learning new design techniquesn and feel smarter about how to tackle even the most complex hairball of an app.

Hagan probably has the biggest collection of application design examples I’ve ever seen. Everytime she delivers her workshops and presentations, she brings out these stunningly amazing sets of both good and bad examples. You can instantly see how changing a design in just a few simple steps can immediately make for a better user experience.

This year, I’ve been working with Hagan on her full-day workshop for the User Interface 16 Conference. She’s putting together a intense program, where you’ll walk through practically every type of interface element, from tables and lists, to working with trees, forms, and wizards. She’ll tackle the gnarly topics of simplifying a complex navigation scheme and creating an effective dashboard display.

Anyone who is fighting design entropy, trying to get their application’s UI under control will be riveted by this in-depth workshop. I’m so happy Hagan’s on our UI16 program and I know you’ll love her session.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

What is a good success rate for a usability test task?
We just conducted user testing on a site map. So we have success rate percentages for each task. They range from 9% – 51% success (in up to 3 tries). Obviously there are problems. (And no, we didn’t create the site map, which makes me feel good.) But what would be considered a “good” success rate? I want to say over 70% for this test. It is only site map, no content, which will limit the success anyway. Maybe I’m aiming too high?

Thinking in terms of % of completion may not be the right approach. (In fact, I’m hard pressed to come up with a time when it is the right approach.)

You haven’t said anything about who the users are or what the site map information contains. But let’s pretend the users are doctors and nurses and the site map contains the necessary information for them to administer drugs safely. If one of those doctors or nurses doesn’t find the information they need, they could improperly administer a treatment which could kill their patient. What would be an acceptable failure rate under these conditions? I’d say 0% — the system needs to ensure success of every user.

Why is your system any less important? Why would you be willing to tolerate any failures?

The real question isn’t “what is an acceptable level of failures?” The question I think you want is “What’s preventing people from succeeding?”

Instead of looking at how many people succeed versus how many fail, what if you were to analyze the failures themselves. Can you rank and categorize all the things that prevent your users from succeeding? Can you assign a classification that helps you understand whether the problems are life and death (as in the example of doctors and nurses I used above), problems that will lose customers, problems that will cost support money, and problems that are annoying without painful side effects?

This will also help you look at the participants you’re recruiting for your study. How similar are they to real users? How realistic are the tasks you’re asking them to complete? How well does the system, if they make a mistake at the site map, help them still succeed by having guidance for common errors on the content pages themselves? (Such as “If you’re looking for x, click here.” type lateral navigation.)

In the end, you really want to understand the problems real users will encounter. That’s the purpose for the studies. Then you want to explore solutions that resolve those problems. In an ideal world, it’s not that you get 100% task completion, it’s that you have addressed and solved all the problems.

The closer you can get your studies to map true in-the-wild user behavior, the more you’ll understand about the problems you’re uncovering and the solutions that will help. Focus on the problems and their resolution and you’ll get the design to where you’d like it to be.

We’re such big fans of the process that I wrote an article about it several years ago. It also happens to be one of our most popular articles.

In our office, we probably conduct a KJ once a month. The KJ Technique is a great way to align everyone to the main objectives and priorities. We often go back to the results during projects to ensure we’re on the right path and help answer additional questions.

In today’s tips, we’re reprinting the article, The KJ Technique: A Group Process for Establishing Priorities. If you haven’t conducted a KJ analysis, you should try it with your team. This article gives you the step-by-step process to conduct your own. For those familiar with it, this article is a nice refresher.

Read the article The KJ-Technique – A Group Process for Establishing Priorities.

“Hi. I’m a designer at [a big deal company] and I’m considering leaving. The problem I have is my employer has made it very clear I can’t use anything I’ve done here in my portfolio. What should I do?”

The work product lockdown is something many designers face, as they grow their careers and try out new opportunities. It’s natural that prospective future employers will want to see what you’ve done. It’s hard to show them when your designs, sketches, and deliverables are locked up behind a corporate non-disclosure agreement.

In future posts, I’m planning on talking about what people can show in their portfolio if they don’t have work products available (or even if they do), and what the best hiring managers look for when reviewing a portfolio.

However, today I want to talk about this from a different angle: Making it part of the hiring agreement.

I think every designer (especially every experienced, senior designer) considering a job at a new organization should ask explicitly about the hiring organization’s policy on including the work in future portfolios. Their answer should be on the table and negotiated, just like salary and benefits.

When should you ask?

In any hiring process, there’s two stages: The first stage is when you, as the candidate, get the hiring manager and company to fall in love with you. It’s all about showing what you can do and how you’ll help them achieve their goals for the position. You’re goal in this stage is to get the company to think you’re the most awesome person ever for their position and they should jump through every hoop to get you on board.

The second stage is when the company gets you to fall in love with them. Their goal in this stage is to prove to you that they are the best place ever.

It’s in the second stage that we can talk about the portfolio, between when they fall in love with you and when you are deciding the job is the right next step. It’s quite within the rules to say, “What’s your policy on employees including screen shots, sketches, and other work deliverables in their portfolio?”

The hiring manager may not know. It may be something they’ll have to ask HR or even the legal office about. At small companies, they have never even considered the question because you’re the first to ask.

However, it’s a really fair question. And, frankly, any answer is a fair answer.

They might say they want to protect their designs from getting in the hands of the competitors. Therefore their policy is to refuse permission to publish work (especially unreleased design work).

Public companies, who have trouble when future plans are leaked, thereby creating a possibility of “insider information” getting out, are very likely to refuse this without including a Safe Harbor statement. (A safe harbor statement basically says that investors shouldn’t use the information as any indication that the company intends to do anything with it.)

Or they might say they have no problem with you putting the documents into your portfolio, but they’d prefer that you don’t put it in a publicly accessible place, like a web site that anyone can get to. They might like you to only show it to people on an as needed basis, asking those individuals to not share it beyond their own team.

Ideally, they come back and say it’s perfectly fine. There’s not reason you can’t take your work with you as you grown your career. (After all, they benefited from your previous employer’s generosity in this matter. Pay it forward.)

Any of these answers are ok. The point isn’t that you badger them into heading in a direction that they aren’t comfortable with. The point is they tell you, up front, before you take the job.

Once you know, you can decide if this is a deal breaker or not. The fact that you asked tells the hiring manager that it’s an important detail to you. That you’re thinking about your long-term career.

(Of course, one argument is that it sends a message that you’re thinking about leaving the company even before you got the job. Personally, I think that’s ok. In this day and age, we don’t expect life time employees. Any company in denial of that fact may not be the kind of place we want to work. It’s good for an employer to realize that each employee has a choice to stay or go.)

As a discipline, our goal is to bring awareness to the hiring companies. To let them know that this issue is an important one for many professionals.

We’ll know we’ve succeeded when hiring companies start putting their openness to including work products in portfolios into their recruiting ads. When they cite unlocked work products as a benefit of choosing them to work there, we’ve arrived.

Then, someday, this will disappear as an issue, as it becomes part of the standard way we all do business.

Sure, critique should be constructive and impartial, yet it’s inevitable that you’ll occasionally disagree with the feedback you receive. Critique is a crunch moment for the undercover designer—you’re sticking your neck out and taking the lead of the design process. However, stakeholders sometimes see design as a complex, unpredictable subject that can cause havoc in the wrong hands. Who wants to let a bull loose in their china shop?

In today’s UIEtips, Cennydd Bowles shares an excerpt from Undercover User Experience Design, a book he co-wrote with James Box. Cennydd outlines his advice for winning a UX debate and explains what to do when you disagree with the feedback you receive on your design. We love this book, and think this excerpt is a great way to immerse yourself in his concept of undercover UX design.

Read the article: Winning a User Experience Debate

It just so happens that Cennydd is conducting our next virtual seminar on July 21: UX Design when Time, Money, and Support is Limited. At the end of this seminar, you’ll be able to put UX principles into practice in any organization, and learn how to make the case for user experience design with results, not theory. Learn more about this virtual seminar.

As I suggested in my post on special collections, I think there is something to Lean UX. It was created as a response to Lean Startups, a movement that I think has merit too.

Lean UX is about reducing deliverables and moving towards thinking about the design. While there are no new skills to add to our UX skill list, there’s a line of thinking that is special to Lean UX that you don’t see when people aren’t practicing it.

Primarily, it’s about getting the UX practice as close to the development cycle as you can. It tends to focus on building working prototypes and getting feedback quickly.

Of course, regular UX has always wanted to have fast iterations, but the waterfall approach of specifying design requirements and working out complete designs before coding starts has been pervasive in many organizations.

The deal is that startups can’t afford a lot of “thinking” time associated with a waterfall-esque design process. They have a limited runway (the time it takes to launch a product) and they need designs fast.

Before Lean UX, the startup method of design was to just take whatever emerged from the architecture of the system. Developers were frequently creating the screens themselves, often without any consideration for what we’d call “design.” Their goal was to get something – anything – up and running as soon as possible.

Lean UX says, “we can help get something better.” It brings a deliberate design ethic to the startup process. However, it has to live within the limited runway environment, therefore it can’t be expensive and time consuming. Designs have to come quickly.

Someone who has spent time designing in this world will develop experience and knowledge that’ll provide value. UX professionals that haven’t had a chance to gain this specific flavor of experience will struggle in the startup world.

Interestingly, I think we’ll see a lot of what happens in lean UX environments feeding back into our thinking in non-lean environments. Hopefully, we’ll start to question the footprint of our processes and ask which deliverables are really necessary. Maybe the real contribution of lean UX is making us all aware of how un-lean much of our work really is.

He was a seasoned consultant himself and I had asked him what I should know, just starting out. He told me his First Rule of Consulting:

No matter how much you try, you can’t stop people from sticking beans up their nose.

That was it. Beans up the nose. Really.

At the time, I thought he was nuts. Now, I’ve come to realize those are words to live by.

The idea is blindingly simple, actually. Every so often, you’ll run into someone with beans who has, for no good reason, decided to put them up their own nose. Way up there. In a place where beans should not go.

Now, there is no logical explanation for this. There is no way to say, “Yes, I can see exactly why you’d want to do that.” They came to this decision all on their own. The way they got to this decision defies logic.

Yet, here they are. Waiting for the moment when the bean goes up the nose.

And here’s the thing: As an observer of this decision’s outcome, all we can do is cringe. We can try to argue. We can explain in the utmost rational terms why this is a bad idea. We can physically grab their arm and shake the bean from it.

Yet, if they are intent on sticking the bean up the nose, up the nose it will go. There’s nothing you can do to stop it. Pure and simple.

I’m sure you run into them all the time. You’re in a room and someone with power has decided to do something that just doesn’t make sense. You’ve tried logic. You’ve tried rational discourse. Yet, they are intent.

Beans and noses. We have beans. We have a nose. They must be united.

Time and time again, I come across situations where I think, “OMG! They are trying to stick beans up their nose!” It explains what’s happening and what I should do next.

The only thing I can do in a beans-and-noses situation (notice my clever use of flight-attendant grammar forms?) is wait. Wait until the bean is in its final resting place. Then, with a calmness only seen in yoga instructors, I can turn the nose owner and ask, “So, how is that working for you? Did it do everything you’d hoped?”

Of course, if they answer they enjoyed it and it was wonderful, then they are not someone I can relate to or help in any way.

However, if sticking a bean deep into their nostril doesn’t meet the very high expectations they’d had, I can now start talking alternative approaches to reaching those expectations.

Often, when I see an oncoming beans-and-noses scenario unfolding before me, I’ll ask about those expectations. How will they know if it’s successful? What will life be like once the bean is firmly implanted?

Maybe, by talking about the outcome, they might see alternative ways of achieving it that won’t result in the misery that comes from a nasal-based legume implantation experience. They might realize they have choices before they commit the act.

That only works half the time. The other half, the bean starts its wayward journey.

That’s when I move on. I decide I can’t be of further help and go take my skills, experience, and knowledge to others. Others that aren’t about to stick beans up their noses. There are plenty of those. And it’s much less frustrating for everyone involved.

We’ve identified a bunch of skills that make up user experience design.

Skills necessary in UX teams

These include the core skills:

• Interaction Design
• Information Architecture
• Visual Design
• User Research
• Information Design
• Design Process Management
• Copywriting
• Editing and Curation

Then there are what we call the ‘enterprise skills’:

• Domain Knowledge
• Business Knowledge
• ROI
• Technology
• Marketing
• Social Networks
• Use Cases
• Ethnography
• Analytics
• Agile Methods

Beyond that, there are a collection of soft skills:

• Storytelling
• Sketching
• Critiquing
• Presenting
• Facilitating

And these likely aren’t the complete set for many teams. It’s just the starting list that covers that vast majority of teams we’ve studied. (If you’re not sure what these are, I’ve described each of the core and enterprise skills when I talked about our team assessment process and the soft skills in my article, Five Indispensable Skills for UX Mastery.)

These are the skills that a great UX team needs to succeed. When teams are missing some of these skills, the chances they’ll produce a great UX is diminished.

When Content Strategy burst onto the scene a few years back, we asked ourselves if this was a new skill (or set of skills) that we had to add to our list? After careful study, we decided we didn’t need to.

That’s because what makes up today’s idea of content strategy is covered in this list already. Teams excelling at content strategy are applying these skills to make it happen with copywriting, editing & curation, marketing, domain knowledge, business knowledge, information architecture, and others.

Yet, we felt content strategy was something different than what we’d seen before. That’s why we labeled it a special collection.

People who practice these skills while focused on content strategy will gain experience and knowledge that comes from the attention to those objectives. This is experience and knowledge that will separate them from people who haven’t focused on content strategy, yet practiced the same skills.

The same is true for service design and for what people are now calling lean UX. These are also special collections, aimed at specific objectives. The underlying skills are the same, but the focus makes it special.

I think there’s plenty of room for special collections. It’s a natural outgrowth of our field maturing. There will be specific conferences, books, and other skill-growing materials that emerge to support people diving into these specialties.

It all makes sense and fits into the model we have of what it means to create great experiences. Personally, I’m excited about it.

For the past few years, we’ve been researching why so many persona projects have such dismal results. We discovered there are basic factors that are critical for a project’s success, yet most teams ignored them.

In today’s UIEtips, I discuss five of these factors. We look at the role of research, who should be involved in the personas, and other essentials that differentiates between a successful persona project and a failed one. I’m sure you’ll find it helpful for planning your projects.

Read the article: Five Factors for Successful Persona Projects

While I’m on the subject of UX techniques, I’m really looking forward to Cennydd Bowles’ upcoming UIE Virtual Seminar on UX Design when Time, Money, and Support is Limited. Cennydd is a kick-ass presenter and his book, Undercover User Experience Design, is a brand new classic. Find out more about the seminar.

Have you tried to use personas in your projects? What have you found to be the keys to your project’s success (or the reason for your project’s demise)? We’d love to hear your thoughts below.

One such podcast interview was with Dan Rubin in a follow up to his webinar on visual design tips for non-designers. Dan is an amazing designer and part of the talented Sidebar Creative collective (they do the Web Design Masterclass). We found Dan’s information so valuable we thought it was article worthy. So we took part of the transcript of his podcast with Adam Churchill and turned it into this week’s UIEtips article. After reading this article you’ll definitely want to hear the whole podcast.

Read the article, Visual Design Essentials for Non-Designers

In addition to being a great designer, Dan is a great teacher. You can learn from him and the other members of Sidebar Creative in a personal, hands-on environment at the Web Design Masterclass in Los Angeles on August 16. For all the details on this intensive one-day workshop, visit http://sidebarworkshops.com.

If you can’t make it out to LA, you can also catch Dan’s next Virtual Seminar on June 30, CSS3 for Everyone.

Many professional writers, before sitting down for the day to write their master works, will just bang out 750 words of no consequence, an activity called pre-writing. (Merlin Mann refers to this as “making that clackity noise.”)

Warming up is another type of practicing. When we warm up, we’re just getting ourselves — both physically and mentally — ready for work we’re about to do.

In baseball, before a new pitcher comes on the field, he warms up in the bullpen. Then, once on the field, he throws several pitches to the catcher, to warm up on the mound. Meanwhile, the rest of the team in the field is tossing the ball between themselves. The batters warm up “on-deck”, swinging the bat a few times, before stepping up to the plate.

Performing artists also warm up. In addition to tuning their instruments, they play a few bars or scales. Singers have voice warm-ups. Actors have acting warm ups.

What would warm-up exercises look like for a UX professional? I’ve been wracking my brain on this and don’t have any good examples.

I’ve never seen a UX professional do warm up exercises — they always just jump into the work. Is it the case that we don’t need the warm up? Or are we missing an opportunity here?

What warm up exercises have you done? What ideas do you have for warm up exercises?

Kate Brigham and her group at PatientsLikeMe are doing amazing work when it comes to online communities. They’ve created and nurtured an environment where patients can share information and their stories through data visualization. Below is part of the transcript from my interview with Kate earlier this year. After you read the article, you’ll definitely want to hear the rest of the podcast and encourage anyone you know with a chronic or life changing illness to explore PatientsLikeMe.com.

Read the article, Building a Community through Stories and Data or listen to the podcast.

And you can hear Kate in person at our last stop of the Web App Masters Tour
in Minneapolis on June 27-28. Get all the details of her talk and the 8 other masters at www.UIETour.com.

If you haven’t explored the UIE podcast library (hopefully you knew of its existence), it’s time you did. Many of our upcoming UIE Virtual Seminar presenters, like Dan Brown and Dan Rubin (our June webinars) have podcasts. It’s a good way to hear their expertise and see why we think they’re so great. Explore the podcast library.

Yes, you read that right. A blind person driving a car. Not an autonomous car that drives a blind person around, but a car where the blind driver is getting feedback and making real driving decisions in real time.

They’ve created an amazing set of devices to make this work. One that impressed me the most was the AirPix, a tablet-like device that uses small holes blowing air to substitute for visual picture. By waiving your hand over the air bursts, the user can get a strong sense of the terrain. It’s Google Maps through air. Brilliant.

Virginia Tech's AirPix Kinestetic Display

Watch the video. You’ll be blown away.

In his thoughtful comment, he stated that he tries to leave the team better than when he arrived, by training them to do the things he does, so they can continue on without him.

“My goal is not to swoop in and save the day, but rather turn those who stay into superheroes. I don’t make products better, I make people better. If agency staff are not doing this, they are most certainly prone to becoming guilty of everything you said here. But if they care about the long-term outcome, they’re leaving clients with much more than deliverables and innovations. They’re leaving clients with a path to better decisions.”

This is exactly what we do in our work with teams, so I think this is a grand goal.

I’m wondering how many design agencies, when they are pitching a project to a client, focus on the “What your team will learn from our work” section of their pitch? Or how many even have such a section?

I’ve sat through many pitches on behalf of our clients. (Teams often hire us to help them choose their agency, because of the knowledge we have on what makes an excellent design.)

I’ve never seen a single “What you’ll learn” section in the pitch. However, I think it should be there.

Hiring clients should demand this from the agencies they are considering. It should be a solid curriculum, with milestones, deliverables, and a list of who is going to learn what. Most importantly, it should talk about everything the team needs to learn, to keep up the good work, once the agency has moved on (and they ALWAYS move on).

I think any agency that makes this a major part of their pitch will have a huge advantage over the competitors who omit it or play it down.

And we’ll get better experiences in the long run.

As we study how teams can best use design principles, we’ve discovered that project specific principles are far more useful than generic overarching principles, which many teams develop. Take Facebook’s published principles, which include generic phrases like clean, human, and universal. Good thing to strive for, for sure.

But how do these principles help the design team? How does a team decide if a design idea is human enough? And if they aren’t for the design team, who are they for?

What we’ve realized is good principles don’t tell the design team what to do. They tell the team what not to do.

A good principle clearly draws a line in the sand, telling you exactly why the majority of ideas you’re looking at won’t cut it. It helps you say, “This isn’t quite there, let’s try again.”

One team we’ve worked with recently was working on a point of sale system for appointment-based businesses. Several operations, such as rescheduling appointments, took time. Watching the receptionists during a rescheduling, the team realized that they had a problem. If another customer called or tried to check out, the receptionist had to make the second customer wait until the rescheduling was done.

The team realized, for their redesign of this functionality, they needed to follow a principle of “Allow for multitasking to handle interruptions.” It’s a simple principle, generated completely from the problems the team saw in their field observations.

What’s beautiful about this principle is it helps the team say NO to ideas. Any design proposal that can’t easily be interrupted for a new appointment or to check a customer out is immediately out of the game.

Sometimes, it might only take a few tweaks to go from “not meeting the principle” to “meets and exceeds.” And that’s perfect — the principle is doing its job of guiding the team to a better design solution.

Years ago, we found when you gave a team of designers a specific problem to solve, they had no trouble coming up with solutions. Solutions are the easy part. Understanding the real problem is the hard part.

An actionable, research-based set of design principles helps a team define and understand the problem. That gives them the power to come up with solutions that really work for the users.

I find this interesting because most UX professionals I know never practice. Sure, they work hard, gaining experience on each project, which does make them better at what they do.

But working is different from practicing. Practicing lets us step back and really look hard at how we do our job, not just what we produce. It’s a critical component to getting better and most of us don’t do it enough.

In today’s UIEtips, we take a hard look at practicing. We look at different approaches, seeing what people working in other professions use to stay at the top of their game.

Read the article Developing a UX Practice of Practicing.

And don’t miss Dan Brown’s upcoming online seminar on Survival Skills for Design Teams. Dan runs one of the best design teams we’ve ever had the pleasure to meet. Hear his secrets to ensuring project success by focusing on the critical soft skills. Find out more about Dan’s seminar.

It’s definitely something I said. In fact, I can tell you exactly what I said.

However, to do that, we need to revisit some research we’ve conducted over the last few years. We’ve been looking at the process of making design decisions and realized there are five distinct styles. (If you haven’t read or seen me talk about these, go read about them now. Otherwise this won’t make a lot of sense.)

If you’re a designer, any of these styles can produce great results that delights customers. However, for many, the most advanced styles, activity-focused and experience-focused design, are the more desirable projects. That’s where the really cool stuff happens and where the biggest challenges are found.

And this is where I get in trouble with the agency folks. As we’ve been researching these five styles, we found an interesting finding: agencies can’t do activity-focused or experience-focused design.

Many do self design. Some very successful agencies make a lot of money with genius design. (And there are many that do unintentional design, but they probably shouldn’t brag about that.) However, it seems activity-focused and experience-focused design is out of reach of the agency world.

Now, many agencies try to sell themselves as doing this work. And many agencies get clients to hire them to do this work. That’s not what I’m talking about.

I’m talking about creating successful designs using these decision styles. That doesn’t happen with an agency. It can only happen in-house.

Activity-focused design takes a long time. It requires making an investment. The team accrues knowledge over a long period, studying users and their activities, implementing solutions, and seeing how those solutions work. It takes many iterations to do well.

Most agencies aren’t brought in for long-term iterative work. Eventually, all agencies leave. When they leave, the knowledge the team has gained walks out the door with them. Then the client is left with something they don’t know how to maintain or improve. The project fails.

Experience-focused design is even more difficult. The designs often require changes at touch points all over the organization. For example, for a retail business to create a seamless experience, they’ll have to change things on the web site, in the stores, at the call center, in the distribution centers, and in the merchandizing department.

Agencies can’t have this kind of reach. It takes commitment at all levels. It’s too expensive to teach an agency how your business works. They don’t have the political clout to make the hard decisions.

Sure, a company can hire an agency to give them ideas. Agencies have really smart folks with lots of great ideas. But the long-term, in-depth execution has to come from within. The company has to make the commitment to investing on their own.

Needless to say, statements like this don’t make me popular with agencies. Recently, I’ve found myself sitting in front of agency owners, defending this position. They don’t like it at all.

I could be wrong. (It’s happened before.) It could be that an agency could take over the management and operations of a business and build a fabulous design using activity-focused or experience-focused design. I haven’t found one yet, but it could happen.

I just hope that agency’s contract never ends, because then their (now former) client is screwed.

In this article, I concentrate on the various skills required for a successful UX team. Through our years of research, we’ve been looking carefully at how to put a user experience team together. We’ve studied dozens of teams, some that are very good at producing great designs, while others regularly struggle to produce anything that makes users happy. As we’ve looked at the differences between the teams, we’ve started to notice some patterns.

One emerging pattern focuses on the skills found in the team. While it’s a no-brainer to say that the more skilled the team, the better the results, it’s more difficult to hone in on the specific skills that make a difference.

Our research has isolated eighteen skills that the best teams all master. We’ve divided these into two groups: Core UX Skills that are unique to the user experience process and Enterprise UX Skills that the team shares with other parts of the organization, such as marketing, IT, and product management.

This article looks at team skills and a simple method for assessing where a team is at. Managers can use this assessment to identify areas of improvements for the team as a whole
and individual members.

Read the article: Assessing Your Team’s UX Skills.

Continuing on the theme of evaluating team skills is Dan Brown’s June 23 UIE
Virtual Seminar, Plays Well With Others: Survival Skills for Design Teams. Dan will show you how to assess talent and skills available to team leaders for more efficient and effective projects. And designers
will understand what they need to best fit in on an effective team. Learn more about this webinar.

OK, maybe I’m exaggerating a little. But I am quite frequently asked to convince executives to invest in user experience.

And it may surprise you to learn that I refuse the offer every time. As a policy here at UIE, we only take on work we can guarantee results from. I know from experience that I have no chance in hell to convince any executives of anything, so I politely decline the gig.

“But surely, because of all your success, you must know what it takes to convince an executive to invest in UX?” they always ask.

Actually, I don’t. I’ve been pitching our services for 23 years and I’ve never once successfully convinced an executive of anything.

Our success has always come from projects where the client team, including the senior management, already understood the value of great user experiences. I haven’t convinced them because they didn’t need convincing.

Have you ever met a smoker? Of course you have. Have you ever met a smoker who didn’t know the harmful effects of smoking? I bet not. Every smoker I know is well aware of what smoking does to their bodies, yet they continue to smoke. There are physical, cultural, and behavioral forces that make it hard to quit.

You can’t convince a smoker to quit smoking. They need to just decide they’ll do it. On their own. When they are ready.

It’s the same with executives. Neither I, you, nor anybody else can convince an executive to invest in user experience.

Sure, there may be a few execs that are somehow still unaware of how a delightful, useful, easy-to-use product is better than a frustrating, useless, difficult-to-work product. I haven’t met one in all my years, but they could exist. Even so, I don’t believe a presentation will change their views.

What can you do instead of a presentation?

You can find out what your executives are already convinced of. If they are any good at what they do, they likely have something they want to improve. It’s likely to be related to improving revenues, reducing costs, increasing the number of new customers, increasing the sales from existing customers, or increasing shareholder value.

Good UX can help with each of those things. The problem is that there is no generic, always-saves-the-world process or solution for any of these improvements. If you wanted me to help, I’d have to study your business in-depth to learn how to make improvements in these areas through solid UX investment.

(That’s a project we’ll accept AND guarantee by the way. We’ve done it before, many times. It’s expensive, but it produces great results.)

Once you start talking about what the executives are already convinced of, it becomes easier to get them to make investments. You’re no longer trying to get them to change their focus. You’re playing directly into their main field of attention.

A generic presentation about how Apple or some other company has a great user experience program (or worse, a presentation showing all the bad user experiences in the world), won’t convince anyone of doing anything different.

You’ll need to do something custom. Something specific to their current focus.

And if that doesn’t work, maybe it’s time for you to find someplace else to work. Someplace where the executives are already convinced and want to make the investment. Right now, there are plenty of these opportunities on the market. Why bang your head against a wall when you can be doing those things you love?

Not every job will require that a designer know how to code. However, there are three reasons why learning to code makes you a better designer:

1. You’ll better understand the medium you’re working in. If you know what database queries will be faster than others, you can make the right response time tradeoffs. If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster (and more of them, since development time is a limited resource.) Understanding what your medium does well and where isn’t as effective makes for more informed design decisions.
2. Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.
3. Knowing how to code helps you identify bugs and flaws in the production code. As your team’s designs start to come to life, you can play an essential role of helping the developers isolate interaction problems, which means your end product will be the best it can be.

There’s been a lot of debate as to what languages designers should learn to code in. Based on these three reasons, I think it needs to be the languages used by the rest of the team, whatever they may be.

It’s clear from our research that designers who can code bring more to the team and, in the long run, see more of their brilliant work making it through the development process, to the user.

The last stop of the UIE Web App Masters Tour is in Minneapolis, June 27-28. Hundreds of web application designers, from all over have found inspiration from our world-class experts. Experience it yourself later this month. And below, you’ll find a special offer to help make attending this Tour stop a little easier.

The UIE Web App Masters Tour is coming to an end. I’m sad because I really wish we could keep going, bringing this merry band of thought leaders to designers all over the world. I’m excited because every tour stop gets better than the last. Minneapolis is sure to be our best.

But don’t just take our word on how awesome this Tour is. Here’s what some past attendees had to say:

I received valuable, instantly applicable action items that will improve my products with regards to design and user search.
– Seattle attendee

I went to #UIEWAMT to find a direction and you guys definitely provided me with one. Many, many thanks.
– @PattiHermoso

We loved our experience at #UIEWAMT and found the content very valuable for our current environment. Thank you to all the presenters!
- @cognitionstudio

Absolutely one of the BEST conferences I’ve been to. Each speaker brought valuable lessons we can take away with us.
- Philadelphia attendee

This Tour Changes the Way You Design

Across two days, nine leading experts in web-based application design share their experience and wisdom, to show you concrete examples on how to take your work to new levels. They tackle the issues of mobile strategy, data visualization, design patterns, engagement, and process best practices. Attendees come away with a full brain and a pile of new ideas, ready to start making improvements right away.

These 9 Masters rock this Tour.

Stephen Anderson shows us how to engage users by presenting information in a clearer and more precise manner.

Josh Clark tackles the question of building a web-based interface or implementing a native app.

Luke Wroblewski dazzles us on how to think about and design for Web organization, actions, inputs, and layout on small screens.

Noah Iliinsky demonstrates how to turn mountains of data into beautiful visualizations.

Bill Scott shares his collection of design patterns and best practices for creating immersing and rich experiences.

Kate Brigham describes how PatientsLikeMe translates data that is mind-boggling in complexity into useful simplicity.

Aviva Rosenstein gives you a peek on how Salesforce.com take advantage of cutting-edge UX techniques.

Mike Lee explains how his team at AARP incorporates a design strategy through major organizational changes.

Jared Spool shares the latest UIE research in two presentations.

Read all about each Master’s session on the web site.

Special Deal for Our Blog Readers

It would be downright awful if you missed this last tour stop. So we’ve put together a special deal. Just use the promotion code TOURBLOG when you register and you’ll get the $895 price – $200 off from the final price. Be sure to register by June 21 to get this discount.

Don’t miss the event of a lifetime. Join us in Minneapolis and inject new energy and inspiration into your designs.

Pam Rodriguez and Luke Wroblewski did a nice job of posting their notes. Thanks guys!

• Steve Portigal on Design Fieldwork: Uncovering Innovation from the Outside In – Pam’s notes, Luke’s notes.
• Kate Brigham on PatientsLikeMe: Adventures with Data Visualizations – Pam’s Notes, Luke’s Notes.
• Luke Wroblewski on Designing Mobile Web Experiences – Pam’s Notes.
• Mike Lee on AARP: Designing a Strategy for Organizational Transformations – Pam’s Notes, Luke’s Notes.
• My presentation on The Essential Principles behind Great Design Principles – Pam’s Notes.

As you can see from the #UIEWAMT Twitter stream, everybody had a great time and we all learned a ton.

There’s one more stop on the 2011 tour – Minneapolis on June 27-28. Use the promo code BLOG and get $100 off the registration price.

See you there!

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Minneapolis

To understand what it takes to create great designs, we’ve spent time with dozens of teams, some of whom are great at getting creative engaging designs out the door. And some that, well, could use a little more practice. Or something.

And we now have a handle on what that something is. In today’s UIEtips, I talk about an important difference between the best and not-so-best teams. Read the article to find out who should be on your team.

What are you doing to keep your team as productive as possible? How are you embracing your extended design team members? Leave your ideas and thoughts below.

If you’re a designer, imagine you had a chance to work with two development teams.

Team 1: One team has top-notch developers who know virtually nothing about design. They can code miracles, but the designs of their applications are horrible and frustrating to use. And they show no desire to learn anything about design — how it’s done, why it’s important, and what makes a good design versus a bad design.

Team 2: The second team also has world-class developers, but these guys are hungry to learn about design. They’ve already taught themselves a fair amount and are truly interested in learning more. In addition to producing amazing code, they are regularly producing applications that look good, work well, and delight users.

As a designer, which team do you think would more fun to work with? The team that has no interest in designing or the one that really enjoys it?

Practically every designer I’ve talked to about this choice has told me, without hesitation, they would love to work with a development team that appreciates good design and wants to learn more about it. Those designers won’t be constantly battling for the simplest of design choices, instead be focusing on the hard problems with a group that wants to see the best outcomes.

Guess what? Developers feel the same way. If they had a choice, they’d rather work with a design team that understands development and craves to learn more, than with a team that doesn’t make any effort to learn what development is all about. Not just simple front-end coding either. They want to work with designers who understand the architecture and infrastructure, who can relate to the challenges they are up against and can appreciate it when the team has pulled off something amazing.

Learning to code doesn’t just give you new skills, it makes you a more desirable team member.

Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.

While hiring super designers has always been floating around, the real demand has come recently out of Silicon Valley startups. With a couple of high-profile design successes, like Apple and Mint.com, the investors and entrepreneurs in the Valley now have a new appreciation for the work of designers.

Startups, however, try to run as lean as possible, so they look for talent with a broad set of skills. The thinking among the Valley folk is, if they can get someone who does both, they can get their product from concept to ship with an ideal set of resources. Otherwise they’d have to hire two people. Or do without one.

We’ve proven for years that you can ship a product without a designer. Many companies have done that, and while it doesn’t make for a great result, it does ship. However, it’s much harder to ship a software product without a coder, if not near impossible.

That’s why, right now, there are dozens of startups looking to pay big bucks to find the coding super designer. The demand is high and those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.

What about the non-startup portion of the hiring world? Right now, the established organizations find it easier to have larger teams with separate developers and designers.

Yet, that doesn’t make the designer that can code any less valuable to them. A team with two coding designers is more flexible and capable than a team with one non-coding designer and a non-designing developer. The flexible team can produce well-designed results better and faster.

Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results. Having a team filled with individuals who can both code and design will be more effective in the long run than a team where the skills are divided up.

If you’re a designer, you don’t have to learn to code. But if you do, and you get good at it, you’ll find more opportunities as time goes on.

In this week’s UIEtips, I share an excerpt of the interview with you. I think this interview with Derek is still fascinating today and worth the read. This is just a taste of what we talked about.

Read the article Accessibility with Derek Featherstone.

Our next UIE Virtual Seminar just so happens to feature Derek Featherstone on Ajax and Accessibility. Derek will share a bundle of tips and advice on how to use Ajax and keep your web site accessible. Find out more about this must-attend webinar.

Blogger Pam Rodriguez has done a tremendous job summarizing the first day’s sessions. You can read them here:

• My talk: Mobilism & UX: Inside the Eye of the Perfect Storm
• Bill Scott’s talk: Designing for Mice and Men
• Josh Clark’s talk: Mobile Apps: Native or Web-Based?
• Noah Iliinsky’s talk: The Steps to Beautiful Visualizations
• Julie Zhuo’s talk: Facebook: Data-Informed vs. Data-Driven Design Decisions

Our own Web App Master, Luke Wroblewski, also has some great summaries:

• My talk: Mobilism & UX: Inside the Eye of the Perfect Storm
• Bill Scott’s talk: Designing for Mice and Men
• Josh Clark’s talk: Mobile Apps: Native or Web-Based?
• Noah Iliinsky’s talk: The Steps to Beautiful Visualizations
• Julie Zhuo’s talk: Facebook: Data-Informed vs. Data-Driven Design Decisions

Thanks to Pam and Luke for taking such great notes.

You can follow along with the second day by following the #UIEWAMT hashtag or the UIE Web App Tour attendee and speaker Twitter list.

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Seattle · Minneapolis

Now the team learned from usability studies that the site wasn’t resonating with the users. They couldn’t understand why. The team incorporated all the ideas and information that the marketing team gave them. Turns out, that was the main problem.

Instead of actually conducting ethnographic interviews with users and building a design around a set of personas, the team developed a design around non-existent research and what the marketing department and executives desired. Ah, if only they created some personas first.

In today’s UIEtips, we look back at an article that Kim Goodwin wrote in 2005. It’s a classic. Everything about it still holds true to this day. Kim discusses how personas affect design and the type of goals to think about when creating personas. If you’re new to personas, this is a must read. And if you’ve been doing personas for a while, it’s a great refresher.

Read the article: Perfecting Your Personas.

Personas are just part of building better designs. The next step is to incorporate personas into scenarios. Luckily, Kim Goodwin is giving our next virtual seminar on just that – Designing with Scenarios: Putting Personas to Work. Learn more about today’s virtual seminar. (We record the seminar so if you can’t make it today, you can listen to it another
time).

Does your team create personas? How have they helped your design? Let us know your thoughts and questions below.

As we’ve been studying what works and what doesn’t work, we’ve realized that the successful teams aren’t doing anything new or novel. Their success is solidly based on a fundamental that many of the struggling teams have forgotten: good design decisions come from informed members of the team.

The big difference that’s arisen in this new agile world is how integrated the team is. No longer is UX design owned by the UX designers: everyone on the team now has design responsibilities. That means that everyone needs to be informed about what the design is trying to do.

When we talked to the teams from the successful organizations, we found a common theme: they used a framework to make sure their teammates have all the information they need. We’ve codified this framework as UX Layers, which span from the big picture of a long-term vision all the way down to the details of individual user stories for developing the next sprint.

In today’s UIEtips, we explore the UX Layers, looking at how they each fit together. Whether you’re currently doing Agile development, planning to move there, or still working in a waterfall world, I think you’ll find this framework will help ensure you’ve got all the information you need to create great designs.

Read the article, Essential UX Layers for Agile and Lean Design Teams.

Want to know more about designing for UX in an agile world? Then you don’t want to miss Julie Zhuo and Aviva Rosenstein’s talks about the amazing techniques that Facebook and Salesforce.com’s teams are using. They are both part of the upcoming UIE Web App Masters Tour. See their sessions and the entire awesome program at UIEtour.com

In this week’s UIEtips, we reach back into the articles archives and look at some of the challenges we’ve seen users encounter in our usability tests. These are challenges to look out for when users interact with your applications. I hope you enjoy it.

Read the article, 3 Important Usability Challenges for Designing Web Apps.

At UIE, a big part of our research agenda focuses on how to create web applications that delight users. We feel it’s so important that we created a conference focusing on web applications. It’s the Web App Masters Tour.

During the 2 day conference, you’ll hear from 9 Masters on mobile design strategy, data visualization and design best practices. Get all the details on the Seattle and Minneapolis stops at http://www.UIETour.com.

Searching on the web is a pretty simple task and most often gets us what we need. Yet when we add another channel into the equation, like going to the store for the product you’re researching, or reaching out to the call center with questions, the search experience can quickly turn poor, becoming frustrating and unproductive.

In today’s UIEtips, Pete Bell breaks down search into 2 basic types: fact finding and discovery. He discusses how these two methods of search affect users’ expectations and experiences and how multi-channels compound the issues. This article is an excerpt from Greg Nudelman’s new book, Designing Search: UX Strategies for eCommerce Success.

Read Pete’s article: Search as a Multi-channel Experience.

Besides reading Pete’s article, you can learn more on how to improve search as a multi-channel experience at our next UIE Virtual Seminar with Pete on Thursday, April 28. And when you register for the webinar, you’ll get a copy of Greg Nudleman’s new book, Designing Search: UX Strategies for eCommerce. Get the details about Pete’s webinar.

We thought we had finally mastered building great applications on the desktop, only to realize that we now have to challenges of the mobile platform to deal with. We now discover that people want to have new insights into the massive amounts of data available. And our design process now needs to be faster than ever.

In building great applications, we have to overcome challenges we’ve never faced before. However, what we’re discovering is that with each new solution, we see happier users and better business results.

In today’s UIEtips, we look at some of these challenges and what they entail. We also see the rewards that come from them and how they delight our users, improve our business, and make the world that much better. I know you’ll enjoy the article.

Read the article Mobile Strategy, Data Visualization, and Design Process: Big Challenges, Big Rewards.

Mobile strategy, data visualization, and the application design process are a big deal. That’s why we’ve decided to tackle them head on in this year’s UIE Web App Master Tour. Join us in Seattle and Minneapolis as experts like Luke Wroblewski, Noah Iliinsky, and Stephen Anderson guide us through the latest thinking and newest approaches to tackling these critical challenges. For more information, see UIETour.com.

Register by May 6 and get the 2010 Web App Masters Tour recordings. Think of it as an appetizer to this year’s Tour.

Business needs can be complex. They come from all over the enterprise, originating from initiatives (like marketing campaigns), infrastructure (like inventory constraints), and regulations (like export restrictions). Suddenly a simple task, like paying for a product, becomes crazy-complicated.

In today’s UIEtips, we look back on an article from January 2010 where I discuss how the best designers thrive within this world of wacky constraints, coming up with ingenious ways to meet the business requirements while ensuring a delightful user experience. If you design web apps, this should be interesting.

Read the article, Web Apps – Where Business Needs and User Needs Collide.

Web app design is at the forefront of our minds this month. We just finished our Philadelphia tour stop, and it was a huge success. Our next stop is Seattle on May 23-24 and then Minneapolis on June 27-28. We’re wicked excited about the program, and I’m betting you’ll be too as soon as you check it out. Go see it at http://www.UIETour.com

Hear the Masters’ Insights on mobile design, data visualization, and design process. Visit UIETour.com