In the last two years, the UX world has seen some drastic changes. Our designs, and the processes to get to them, are undergoing a transformation that forces UX designers to rethink what they do.

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.

There’s definitely an advantage to having your users understand data and messages through a picture versus reading a series of sentences. Information visualization, when done right, can have a greater impact.

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.

Podcast: Play in new window | Download (Duration: 21:09 — 0.0KB)

[ Transcript Available ]

The goal of Lean UX is to take the focus of user-centered design off of documentation and put it squarely on the experience. The way to do this is to view any design idea as a hypothesis. With a focus on the experience, you can validate or invalidate this hypothesis much quicker. The sooner you reach this validation, the sooner you can focus on designing and building the correct solution.

Jeff Gothelf is a firm believer in the Lean UX process. One of the key aspects of Lean UX is how collaborative it is. Jeff says that the separation between design and development really needs to be broken down. That the people who are collaboratively building this experience or product need to be collaborating with each other much more frequently. Jeff discussed the idea of Lean UX in his virtual seminar, Lean UX: Getting Out of the Deliverables Business, and the audience posed a number of great questions.

In this podcast, Jeff and Adam Churchill address the questions that there wasn’t time for during the live seminar.

Here’s an excerpt from the podcast.

“…The core of Lean UX is bringing dev and design into the same time frame. That’s what we’re focusing on now.

To do it successfully, there’s an amount of upfront thinking, at the very least, that’s done by the product and design teams before we plan the next iteration.

There’s a little bit of heads up that says here are the things that we’re likely going to be working on in the next iteration. Let’s do at least a little bit of thinking around that. If there needs to be a little bit of illustration or visualization of that thinking, then it’s very, very lightweight.

It could be a sketch on a piece of paper, it could be a very rough wireframe. We’ve gone into iteration planning meetings where we’ve drawn on the whiteboard and said here’s how we’re thinking about solving this problem.

That engages the entire team in a low-fidelity way of articulating how they think the problem should be solved. Because it’s a sketch or it’s a whiteboard drawing it’s erasable. People can write over it. You can redraw it. You can redo it. That encourages collaborative problem solving…”

Tune in to the podcast to hear Jeff answer these questions:

• How do you validate with the engineering team what they’re going to need before the project starts?
• Does Lean UX require new tools or skills?
• Does the UX team build the wireframes or is it the developers?
• Does Lean UX work for larger, legacy organizations?
• What can you do if you don’t have access to your end users for testing?
• Where does user research fit into this process?
• How do you overcome expectations for wireframes that are already set?
• Does the Lean UX process reduce the number of hours spent on a design?

Do you have experience with Lean UX? Share your thoughts in our comments section.

Recorded: December, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Read the rest of this entry »

Sometimes, it’s easy to brand what we do as the “science of the obvious.” Here we are, doing all this research, and come up with something that is painfully obvious.

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 less than 2 weeks, we’ll launch our web site and registration for our new event – UX Immersion Conference 2012 – Mobile/Agile. This brand new three-day event goes deep to answer your questions around 2 important themes: mobile design and the agile process.

Join us in Portland, Oregon April 23-25. Immerse yourself in 2 full days of workshops from renowned UX specialists and one day of short talks full of tips, techniques, and case studies.

Want to know more? Sign up on our email list and we’ll send you the latest information as soon as it’s available! We promise not to share your address. We hate spam too.

Visualizations are an increasingly popular way designers use to convey complex, data-driven ideas. But with so much data to choose, how do you decide which story is the most appropriate one to tell? And how do you then tell it? On February 2, find out from Noah Iliinsky.

In his UIE Virtual Seminar, Telling the Right Story with Data Visualizations, Noah will provide demo data to teach you how to effectively conceptualize, plan, and ultimately design powerful visualizations that tell the right story. But be advised: you’ll never look at data the same way again.

You’ll learn to:

• Decide what story to tell with your abundance of data
• Choose the best data for telling that story effectively
• Select which encodings best align with the data
• Design visualizations that clearly convey meaning

If you’ve read all the blog posts and still find yourself stumped with how to design visualizations of complex data, then this seminar is right up your alley. Get a step-by-step guide to reviewing, choosing, and designing effective data visualizations.

We’re bringing back Noah Iliinsky to follow up one of the most popular UIE Virtual Seminars of 2011—Information Visualization: Letting Data Tell the Story. Register for his February seminar with the code VISUALIZATION, and we’ll send you access to his first seminar.

UX design in Agile can be a frustrating experience when teams are more focused on delivery over the quality of the experience. But the thinking underlying major Agile methods such as XP or Scrum can be applied to UX design, too. On Tuesday, January 24, Anders Ramsay is going to show you how in our first Next Step Virtual Seminar—Designing with Agile.

You’ll Learn to:

• Play the project game in a different way
• Replace passive collaboration with active collaboration
• Integrate UI design with user stories
• Make UX planning part of the project rhythm

You already know that UX decisions touch every part of a project. But integrating them with Agile to communicate, estimate, and deliver the product is critical to winning.

After this seminar, you’ll be ready to knock it out of the park.

The Next Step Series

The Next Step Series will feature Rosenfeld Media authors covering critical user experience topics just like they do in their Rosenfeld Media books. And by teaming up with UIE, you’ll experience the great format and quality production values you’ve come to expect from our 90 minute-long live seminars.

[This is part 2 of a two-part post. For this article to make sense, you probably want to read part 1. This article was originally published on JohnnyHolland.org.]

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.

Producing a brand new event is exciting. Lots to think about: the speakers, the topics, and the locations. Yet what immediately separates one conference from another is its name.

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 kill design projects. An opinion war happens when two or more people hold strongly held opinions that are in opposition of each other.

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.