Good Article On Why We Still Need Personas

While reconnecting with my colleague Jan Moorman, now a UX researcher at Walmart eCommerce, I found an article she and another practitioner wrote about personas. The main points definitely bear repeating:

  • Half-baked and research-free personas can do more harm than good.
  • To be truly useful, personas should be based on actual research and should focus on “goals, motivations, and expectations.”
  • Ground your personas with (relevant) details from real users.
  • Evangalize your personas.

Regarding points 2 and 3: I’ve always felt that personas containing extraneous personal detail (“Dale is a yoga practitioner who likes skeet shooting and extreme chess and dotes on his 3 bichon frise puppies”) can actually be off-putting instead of empathy-generating. And I’ve also strived to annotate my personas with user profiles to connect them to the raw data. So I was pleased to see them advocating for this as well.

As far as evangelizing personas…well, you’re reading the blog of a guy whose UX team at a former company laminated their user personas and distributed them to the executive team. So yeah.

Love, Hate, and Empathy: Why We Still Need Personas  ::  UXmag



The UX Kit Has Been Updated. Get It Now.

I’ve updated the UX Kit with some good stuff. What’s new? How about:

  • Updated all the UX position descriptions.
  • Added two new position descriptons – UX Strategist and Content Strategist / Information Designer.
  • (At long last) Added a section discussing how UX and Agile processes can work together.
  • Updated the salary info per the 2014 UXPA Salary Survey.

I also updated the Creative Commons license to Attribution-ShareAlike 4.0 International. Which means all this sweet sweet content is yours to use and modify as you see fit.

Please enjoy and share.

Workshop & Talk At UX Strategies Summit

I’m excited to be speaking at the UX Strategies Summit, coming up June 9-11 in downtown San Francisco. I’ll be running a workshop and giving a talk. The workshop is almost full – 8 seats left – and I’d love to see you there.

Workshop: Embedding UX Processes Within Your Ideation, Design, Dev and Release Cycle

Description: The war is over, and UX has won. Thanks to the ubiquity of easy-to-use web applications and mobile apps, everyone from C-levels on down recognize that good user experience design is now just table stakes. It’s part of the cost of doing business.

However, as the saying goes, you can win the war but lose the peace. Even with the best of intentions, many organizations still don’t know how to effectively incorporate UX processes into their product life cycle activities. And they’re looking to you for leadership, UX practitioner, product owner, scrum master, or whoever you are!

In this workshop, we’ll work on:

  • How to identify and cultivate UX champions
  • How to leverage small tactical UX wins to drive toward a strategic UX approach
  • How to get the right UX activities embedded into the right places in your organization’s product life cycle…without giving your stakeholders sticker-shock (or project plan conniption fits)

Talk: Decision Insurance: Iterative Prototyping To Reduce Business Risk

Description: As UX professionals, we appreciate the value of iterative design. After all, who doesn’t want user feedback on a new design or a redesign? It helps us understand where our designs hit the mark, and where we might’ve missed a key user need or misunderstood something about the users’ mental model.

But there’s a whole other level to iterative design: the reduction of business risk. One of my mentors, a VP of Product Management at a former company, asked me why he should let my team take two weeks out of the schedule to test and revise a design in prototype form. I told him our typical UX justifications. When I was done, he looked at me and said “I get it now. You’re my decision insurance. If we make a product decision, you can test it before release.”

In this session, you’ll learn how to position iterative design and testing as a risk mitigation strategy.

Giving Clients What They Need, Not What They (Say They) Want

The aphorism “give the client what they need, not what they say they want” assumes a lot. It assumes that you have the ability to a) recognize what the client actually needs, and more importantly b) convince them that what they say they want is actually not in their best interest.

Many good UX practitioners can progress to the point of knowing what a client needs. But it takes some experience dealing with things like organizational inertia, hidden agendas, and other phenomena to effectively advocate for a different course of action.

One advantage UX practitioners have when entering into this type of conversation is that if you’ve won the work, you have what social psychologists call “expert power” – in simple terms, when you first engage with the client, you’re seen as the expert, and people are willing to listen to you. And if you’re competent, you’ll retain the aura of the expert over the course of the engagement.

Basically, expert power is your leverage. But there are techniques to wielding this power. More on this in a later post.

Straight Up UX Advice

A few UX colleagues and I decided to start a Tumblr called “Straight Up UX Career Advice.” We’ll see how it goes. We’re collecting, well, useful advice for UX’ers that’s more about mindset than tools or techniques. We’ll see how it goes. Will it turn into a vibrant forum? That would be nice.

Required Reading – The End Of Apps As We Know Them

My colleague, former Microsoftie and Sage-ite Steve Cover, posted a link to a thought provoking article on Titled “The End Of Apps As We Know Them“, it claims that designers and developers need to focus more on designing apps as systems that interact with other applications and OS’es, and less as stand-alone destinations. It’s basically an argument for focusing on workflow, which as a UX designer and researcher makes me very happy.

Some of the implications of their claims are almost mind-blowing. Here’s just one. From the article:

“Responsive design is a nice thing, but we’re heading way beyond that. We’re talking about designing content that may appear on an incomprehensible number of devices and in an incomprehensible number of situations. This will need new design principles, new ways of thinking about researching context.”

There’s lots more to chew on in the article, and some great comments too. Check it out.

Read: The End Of Apps As We Know Them

2003 Called…It Wants Its Error Message Back

File this under “anti-pattern”… here’s an error message I received from a web application when I clicked on something after I exceeded the automatic log out timer but the page didn’t refresh.

Obviously this message is ugly and rude, but what else is happening here? Here’s a quick tally:

1. Dev-speak. Most of the message is clearly written for debugging purposes. Why show this to the end users, who in this case are students, instructors, and instructional designers?

2. Who’s the audience? While most of the content is directed at developers and QA testers, there’s the curious directive to “Contact the System Administrator.” Who was this message designed to address? The internal team or the users? Or is this just some sloppy concatenation of messages that gets thoughtlessly barfed onto the screen with no underlying design rationale? (You can guess what I think…)

3. Abdication of responsibility. Let’s revisit that “contact your system administrator” bit. There’s a dismissive, “not our problem” attitude behind this hackneyed phrase that’s not only unhelpful, it’s insulting.

Well-written error messages are supposed to do two things: tell you that something has gone wrong, and provide you with sufficient information or available actions to get back to your task.

So how would I redesign this interaction?

– Remove all the dev-speak.

– Remove that screamingly ugly red bar and “Error” text.

– Add the following content: “You have been automatically signed out. Sign back in below.”

– Add these elements: sign-in control set (username, password, button) and a “Forgot username or password?” link.

It’s 2014. It really isn’t too much to ask for.

 (Click the image to embiggen)