Category: Process

Posted on

Now on SuperYesMore: Preconditions

Alex Duloz, who was one of the brains behind The Pastry Box, asked me to participate in his 2017 project The Human In The Machine. He’s doing a look at productivity and how we handle it, with a post every day about productivity from a different author.

For my post, Preconditions, I thought about my daily routine and what things I do to set myself up for a productive day. Some of them are physical and environmental, like the way my desk is set up or how warmly-dressed I am. Others are about the work itself: is it ready to be worked? How do I know? The list goes on from there.

I don’t have any expectation that anyone else will use my process. More, it was nice to quantify the process I’m using and see it out on paper (well, electrons) so I could confirm it. And a little bit, writing it down helped me look at it and decide whether everything really was of value.

Posted on

Now on The Interconnected: Doing Agile Wrong: Design is not Development

I’ve tweeted a couple of times about a project I’m on where we’re doing a big up-front design. It’s a long project.

Every time I have, someone has replied back to me to tell me that if I’m doing a big up-front design, I’m not doing Agile correctly and I’m going to get burned.

Outside of the fact that it’s incredibly rude to tweet someone and tell them that their process (which the vast majority of us working in big companies get no control over) is wrong, there’s a problem here: there’s nothing wrong with big up-front design.

Explaining why front-loading a development process with a design process has been more difficult than I expected. My first draft was long and rambling. Turned out I really had three posts hiding within it.

My October 7 article for The Interconnected, Doing Agile Wrong: Design is not Development describes the difference between Agile and UX. It’ll be followed by an article on the difference between big up-front software design and big up-front product design. Then sometime after that, we’ll post the final article, which explains when big up-front (product) design is right for a project.

Posted on

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.