Proper use of personas

Seems the in thing to do this spring is critique persona use.

In the last two weeks, I’ve seen tweets stating personas should be anonymized because age, gender, ethnicity, etc. can cause distracting assumptions. I’ve seen tweets that said specificity matters because the point of personas is to build empathy. I’ve seen tweets that maybe personas don’t build empathy very well. I’ve even seen a few people suggest they shouldn’t be used (though I can’t find any of their tweets now).

And if any of that advice is useful to you, go for it.

Here’s some more advice about using personas.1

  1. Personas should be based on user research and analysis. The farther away from user research you wander, the more risk you add to your design project. This is the one universal truth that separates creating personas from writing fiction about the people you wish were using your system.
  2. Personas are deliverables used to track the research and analysis you do about your audience, so you don’t have to keep it all in your head. (Write it down or it never happened!)
  3. Personas are a technique for storing the assumptions and research you had about your audience so a year later you can remember why you thought what you thought.
  4. They are a way to encourage acknowledgment with business sponsors and project teams that you have more than one audience. “Who will use this?” “EVERYONE!” “Try again, Sparky.”
  5. They are a way of teaching new designers to think about users before thinking about solutions. Just the act of identifying personas is educational. I’ve had more than one volentold SharePoint admin exclaim “Oh wow these are fantastic!” when I explained what a persona was.
  6. They are a way of reminding old designers that new designers still exist, and that we can all take a decent trip back to basics every once in a while.
  7. Personas are useful as protection for your research sources. Someone is much more willing to give you their actual views of a process or a goal when their words can’t be traced directly back to them. Personas allow you to anonymize the interviews so that you can bring up important user points of view without a manager storming out of your meeting to go give the interviewee a piece of their mind.
  8. Personas are a method of visualization used to differentiate audiences, so that the team can keep straight all the different actors on the system. (You can’t tell the players without a program.)
  9. They are a way to validate your user research with the people that you interviewed or their managers — “does Jeff seem like he’d be a member of this team? Why or why not?”
  10. They are a fast way to show progress in the user research when the sponsor is getting itchy to see screens. “While I work on that wireframe can you validate this persona and shop it around?”
  11. Personas help the content folks identify audiences for tailoring content, writing audience briefs, etc.
  12. Personas are a framework that folks writing requirements can use to create the actors in use cases or Agile stories.
  13. Personas help validate security and systems requirements in a conversational way when reviewing requirements or detailed design. “Can Taliq access this screen as a service rep or is Wanda the financial planner the only one who has access?”
  14. They are a way of telling stories to walk people through processes and get sign-off on screens.  “Adele clicks here, then fills out this form, then clicks here” makes more sense to most people than “this is the form screen and its exits and entrances.”
  15. Pictures of your personas should be hung all over the project room so that everyone can see the users and remember that’s who we’re building for.
  16. Personas may encourage your project team to empathize with the users.
  17. More importantly, personas encourage you to empathize with the uses.
  18. Personas should only have information relevant to your project because everything else is distracting for the project team.
  19. Personas should have a snapshot of the life of the user because your project is not their life, and the project team needs to be reminded of that. They are a subtle way (or sometimes not-so-subtle way) to remind the project sponsors that users have lives outside of their product and nobody’s visiting your website nineteen times a day “to have a community”.
  20. Personas should be embellished to contain accessibility issues like low vision or deafness to remind the project team to be inclusive.
  21. Personas should concentrate on the user’s tasks and goals, not their ethnicity, age, gender, etc. because those elements might distract the team or cause unneeded assumptions.
  22. Personas should be specific — identifying the user’s ethnicity, age, gender, etc. —  so they’re someone you can picture saying hello to in the hall.
  23. They are a subtle way to remind your project members that black managers exist, women developers exist, deaf customer service reps exist, but the stereotypes in their heads probably don’t exist.
  24. Personas should never be reused, because they should be specific to the project.
  25. Personas should always reused, since the users don’t change just because your project has. (Make sure you revalidate them for each project!)
  26. Over a really really long time Personas can help you spot trends or changes in that audience.
  27. They should never reference the user’s hardware or software.
  28. They should always reference whether the user is on mobile or desktop and what OS they’re using — you know, their hardware and software.
  29. Every time you use personas you should use them the same way, except that’s not actually possible because teams and projects are all different.
  30. Personas, when documented, should fit on one page. Or five pages. Or a full report with a nice summary.
  31. They should always/never/sometimes have pictures.
  32. They should be whatever your boss expects.
  33. They should be whatever your contract stipulates.
  34. They should be whatever your mentors suggest.
  35. They should follow industry advice, unless that advice is worthless or doesn’t apply to you.
  36. They should help you fail faster.
  37. They should help you not fail at all.
  38. Personas have multiple purposes.
  39. Personas meet multiple project goals.
  40. When all is said and done, personas should look like, contain, and be used for whatever the hell makes your work more effective and your project more successful.

1.  I’m an Information Architect working Enterprise projects in Big Financial, so a lot of my examples reference intranet or internal app thinking, but that doesn’t make them invalid for external-user personas.

Now on The Pastry Box: Welcome to Enterprise

This month’s Pastry Box post, Welcome to Enterprise, is really a bit of a rant about user experience design vs. client experience design. Client experience design is when we design something that makes the paying client happy. User experience design is when we work with the client to make the end-user of the product happy. In doing so, we align the users’ needs with the clients needs (and/or make the client aware of irreconcilable differences) and make everyone satisfied.

It’s called Welcome to Enterprise because a) I work in Enterprise software and it’s what I know best, and b) pretty much everyone in Enterprise thinks that *they* are who I’m working for.

I’m not. It’s my job to advocate for the end user, and bring everyone else around to do the same. That’s what UX in Enterprise is about.

Full Stack of Something

Here’s the thing that’s hurting my head today: the “full stack developer” job listing.

A Full Stack Developer is someone who can develop at every layer of the software development stack, from the servers to the front end. This includes:

  • Server, Network, and Hosting Environment.
  • Data Modeling
  • Business Logic
  • API layer / Action Layer / MVC
  • User Interface
  • User Experience
  • Understanding what the customer and the business need.

My role as an Information Architect lands firmly inside of the sixth one down, “User Experience”, and often I’m not the Information Architect on a project, I’m the User Experience Designer. (Even as an Information Architect there are expectations that I can talk fluently about the business logic, user interface, and customer and business needs, so the User Experience container is by no means leakproof.)

User Experience is a huge field of study in and of itself. In the “tradition” of the Full Stack Developer posting, I suspect we should call ourselves “Full Stack Designers” instead of User Experience Designers, because it gives a much better impression of our wide range of responsibilities, which include:

  • Information Architecture
  • Architecture
  • Content creation
  • Visual Design & Information Design
  • Human Factors
  • Industrial Design
  • Interaction Design
  • Human-Computer Interaction
  • Sound Design
  • Interface Design
  • Usability Engineering
  • Content Strategy

…and probably more than I can’t think of.

Each of the topics that makes up a Full Stack Designer can be (and in many cases is) its own full career with its own full educational system, training, and roles in an organization.

For example, I’m thoroughly well-versed in Information Architecture and Interaction Design, comfortable in some of the Usability Engineering methods and knowledge and some of the Content Strategy methods and knowledge (but not others), and not as deep in Visual and Information Design. I can’t even comfortably say I’m a Full Stack Designer (since I’m aware of my own weaknesses and imposter syndrome is a thing).

I suspect the same thing is true of all of the other traits that a Full Stack Developer is supposed to be familiar with.

So how in the world is someone supposed to be a Full Stack Developer and be set up for success by their employer? Is it a significant reliance on vendor products, frameworks, and external knowledge? Is it by only building small websites? I’m baffled.

And suspicious. I should add that I’m suspicious, because to do six careers well takes a lot of time, and while it might come with a lot of salary, I’m having trouble imagining it comes with a lot of sleep. Hustle is hype, and anyone who’s told me otherwise was trying to pay me one salary for at least two jobs worth of work.

Me, I’m happy with one job that pays the bills, the occasional vacation, and a few pinball tournaments or races or Phillies games. And as much as I believe that there’s space for both specialists and generalists (and maybe even a few compartmentalists) I’m also quite a bit worried that anyone working six career paths under one job title is, well, over-generalizing.

I’m worried about the Full Stack Developer precisely because it includes the Full Stack Designer. If an employer believes that the 8+ specialties in my field are nothing but a subset of skills for someone who is already doing 5 other jobs, then what do they think of hiring someone in my field? Are you specializing in IT by being a generalist in Design?

I don’t have answers, just a headache, and an observation that this “full stack” world seems awfully general.

Navigating the jotter pad

As someone who works on the web, I rarely see criticisms of physical objects (Design of Everyday Things doors excepted) that this paragraph from James Ward’s Adventures in Stationery delighted me:

I find jotter pads confusing. The spiral binding across the top makes it easy to take notes, flipping each page over at a feverish rate as words are quickly scribbled down, but I gradually lose sense of what is ‘forwards’ and what is ‘backwards’ within the notebook. I get lost by the middle of the pad. Normally, when trying to find a particular note or idea I hurriedly wrote down, I can at least remember if it is on the left or right page of the notebook or pad and then try to find it that way. The jotter pad offers only vague locative information. That crucial scribble could be anywhere. Notebooks need a ‘search’ function.

Yes, exactly, the sense of environment and direction of a physical left-right page book or notebook is critically important. I can find content in my physical copy of CSS Pocket Reference at ten times the speed I can find it in the Kindle version, and not just because I wrote notes in every margin. There’s both physical and visual memory associated with one’s place in a physical book; the weight of the pages on one side or the other, the look of the way the pages curl, the depth perception of the edge, all contribute to remembering one’s place just as much as the content.

The fact that this happens in jotter pads should have given us a bit of a warning that it was also going to happen on tablets and smartphones. But, humans, meh, what can you do?