Tag: Information Architect

Posted on

Quiet in a time of change

You may have noticed that the site has become… well… UX-related book reviews mostly.

That’s not an accident — I’m reading more than I have in decades, and I do my best to review good books because reviews are a driver for sales, and good authors deserve to be rewarded for being good authors.

But it’s also an acknowledgement that I’m not talking about much else in UX right now. Even on The Interconnected, which is my usual ranting locus, the site was virtually silent last year.

Last year, I think we can all agree, was rough.

This year so far is better but that doesn’t mean much. When I walk the half marathon in Virginia Beach, mile 11 over the damned bridge is hell, but it being stupid hard doesn’t suddenly move the finish line closer.

Still, I think there’s a finish line around the corner, so I shall trudge on until I can fall onto the beach and soak my feet in the ocean.

Things that are looking up:

  • I have a new job at Vertex, Inc. where we design software that calculates sales tax and VAT. I am pro-fair-taxes and also pro-make-taxes-easy, and in a lot of places (for better or worse) sales taxes fund lots of important local initiatives, so at least at the moment it feels like a good fit. I’m two months in and I haven’t seriously pissed anyone off yet, but the day is still young.
  • I’m seeing more and more people in our industry concerned about accessibility and making things more equitable for all, regardless of disability. I refuse to say that the pandemic has any silver linings with 500,000 dead in my country alone. I will say that hard-earned lessons are still lessons, and hopefully we’ll come out of this with more accessible jobs, more accessible websites, and more people giving a damn about their own impacts on their neighbors’ ability to survive in an increasingly technical world.
  • While we’re on the subject of survival, there’ll be a review coming up sometime soon on Sustainable Web Design by Tom Greenwood. I’m about halfway through now and already recommending it to coworkers. Many of the goals in the book align with accessibility goals and good information architecture goals, so I think it could become an asset in convincing our higher-ups (especially in enterprise product design) that good web design = good business, both on the surface and within the code.

I’m also working (slowly) on my own accessibility website, trying to bring together information from the WCAG and the Deque online training classes I’m taking, articles that I rely on, other books, etc.. The ultimate goal is somewhere that people can navigate through a list of components and find something that says “Oh, buttons? Here are all the WCAG guidelines, info on how to hit them, and info on how to test them, all in one place.”

That’s taking longer than I thought it would because

  1. pandemic;
  2. constant exhaustion;
  3. I am the world’s worst estimator.

May you also be within sight of the next milestone, and may your strength hold out until you get there.

Posted on

Everyday Information Architecture by Lisa Maria Martin

I’m a three-time failure at reading the Polar Bear Book.

I’m also a Principal Information Architect with 10 years’ experience.

I’m not telling you not to read the Polar Bear Book. I am telling you that if you want a short, direct, and well-structured book on what Information Architecture is, how to get started practicing it, and real-world examples of prior work, Everyday Information Architecture by Lisa Maria Martin is the book to start with.

It is the IA cohort to The Elements of Content Strategy.  And y’all know I’m a big fan of that book.

I started this book while sitting in a hospital room watching my husband sleep. It’s readable even under extreme stress. The book starts with the LATCH system of organization, which I had learned… but when I’d learned it through the quasi-apprenticeship of a mutual fund company’s design department, it didn’t have a name. So here I was, middle of the afternoon, snoring and beeping filling the room, and ten-year veteran of information architecture, learning things I didn’t know on page 5.

Your milage may vary (YMMV), especially if you’re one of those younger folks for whom information architecture degrees were available. (We had library science but I was too short-sighted to major in it.)

The book is vibrant and well-structured enough that I could put it down for a week at a time if I needed to and pick it up again and keep reading and understand where I’d left off. (Also, YMMV.)

Plus, this book isn’t afraid to use Star Trek, Ravelry, cooking, self-deprecating spreadsheet jokes, and colorful, useful examples.

To sum up, this book is going on the list of books anyone who asks me how to start a career in UX, along with Don’t Make Me Think, How to Make Sense of Any Mess and Universal Principles of Design.

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.
Posted on

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.