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.

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.

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.

Specializing in skills and infrastructure galore

A long time ago I was in a discussion about process as an “innie” – a User Experience team member that works inside a larger organization, generally whose mission is not to deliver UX to someone else. (An “outie”, on the other hand, works at an agency or as a freelancer to provide these same services.)

The outies I was talking to all believed in small development and design teams who could work quickly and easily, adjust to changes, and provide smooth handoffs. And yes, that works, but it’s not the only way.

Recently, Pamela Drouin mentioned that she’d heard some companies make their UX folks specialize in research or design. Having experienced extreme fragmentation, I threatened to tell her stories of specialization that would terrorize her, and she called my bluff.

So here I give you the most complex and bureaucratic design process I was ever a member of, with the highest level of Design role fragmentation I’ve seen. (For the faint-of-heart, please know this structure has since been dismantled… well, most of it, anyway.)

  1. Someone gets an idea, which makes it to the business folks with enough authority to decide it’s worth funding.
  2. The Product Owner writes a Project Charter, passes it through some sort of complex and magical bureaucracy, resulting in a Budget for a Project.
  3. A Business Lead (responsibilities: translate Business to IT and vice versa, always be available to the dev team for business decisions) is assigned to the project.
  4. A Business Systems Analyst (BSA) (responsibilities: schedule all the meetings necessary for gathering requirements, gather requirements, facilitate communication with IT) is assigned to the team.
  5. Depending on the size of the project, the Product Owner, Business Lead, and BSA, along with subject matter experts, market researchers, and other folks, may complete a Business Design Methodology (BDM) project to determine what business problem they’re trying to solve and what approach they want to take.
  6. When the BDM is complete, a Design Vision is kicked off. Someone contacts the Design Manager (responsibilities: manage a design team, participate in critical projects, set overall organization design strategy) and asks for design resources.
  7. The assigned Information Architect (IA) (responsibilities: some design research, determining user needs, business goals, structure, navigation, scenarios, site map, strategy, process flows, page flows, alignment with architectural brand standards, and wireframes) meets with the Product Owner and Business Lead, sets a schedule for the Design Vision, and determines what other designers are needed.
    • If a BDM wasn’t completed or the BDM didn’t cover enough of the research, a Usability Engineer (responsibilities: user research facilitation, personas, design heuristic analysis, usability testing, design research reports) is immediately engaged; otherwise the Usability Engineer is engaged when wireframes are in progress
    • If durable content or news/fresh content is needed, a Content Writer (responsibilities: writing mid-to-long form content, navigating that content through editorial and legal reviews) is engaged.
    • A Web Writer (responsibilities: writing all infrastructure content — labels, buttons, instructions, headers, etc. — and ensuring that they’re coded correctly) is engaged.
    • An Information Designer (ID) (responsibilities: visual display of the page content, charts, graphs, tables, photography, and illustration, all assets to that effect, ensuring design aligns with visual brand standards) is engaged.
  8. The IA puts together the Design Vision Plan so that IT knows when they’ll be engaged for development.
  9. Design Vision meetings occur until the information architecture is stable and wireframes have been developed. All of the people above are required for the meetings in various amounts depending on the day’s topic.
  10. Sometime during this stage, the Usability Engineer runs initial design heuristic reviews or early usability tests and creates a Usability Report, which the Information Architect dispositions with the team.
  11. The IA completes the wireframes in Visio and passes them on to the ID.
  12. The ID “skins” the wireframes in Photoshop.
  13. The IA, Business Lead, and Product Owner present the current state of the project at an Executive Review. The IA facilitates dispositioning the feedback.
  14. If a second usability test is needed for interactive elements, the IA engages an Interaction Designer (IXD) (responsibilities: creation of a prototype using HTML, CSS, and Javascript in a test region to capture interactive behavior and assist with usability test) who then builds HTML prototypes, and the Usability Engineer runs another test.
  15. The Information Architect writes a Design Vision Document outlining all of the design decisions made throughout the Vision including their underlying research, risks, strengths, and which elements of the vision included deep, middling, and shallow analysis. When this is complete, the IA, ID, IXD, Usability Engineer, and probably the Writers are all released from the project.
  16. Right around this time, an Agile team including a BSA (hopefully the same one), Scrum Master, Tech Lead, developers at the database, mid-tier, and front-end levels, a UCD Designer, Systems Acceptance Test Tester (SAT tester), Client Acceptance Test (CAT Tester) and Web Writer (hopefully the same one) are engaged in Sprint Zero planning. Depending on the number of front-end developers, there may be more than one UCD Designer, because it only takes 3 front-end developers to max out a UCD Designer’s capacity.
  17. At the end of Sprint Zero and the beginning of Sprint 1, the BSA begins front-running requirements, and the UCD Designer begins front-running designs specific to the Sprint 1 stories.
  18. From Sprint 1 forward, the UCD Designer (responsibilities: detailed design of all flows, error messaging, prototyping, Page Integrity Test testing (PIT Testing) and facilitation of all design decisions) designs to the detailed requirements, contacting the IA when the detailed requirements conflict with the Design Vision Doc. The UCD Designer also builds a second prototype, this time with component code, determines which parts of the Vision can’t be built using existing component code, and arranges for components to be written or custom code to be delivered for the specific capability.
  19. During each sprint the UCD Designer works with the Writer to ensure the content is correct and applied, validates testing scenarios and requirements, and documents the Design Specs for the project.
  20. At least one usability test is required, so the UCD Designer engages (hopefully the same) Usability Engineer. The UCD Designer also participates in the required executive review. The UCD Designer dispositions all the feedback from both reviews with the team.
  21. During each sprint and again during regression, the UCD Designer PIT tests all visual design elements of the pages or application being changed to ensure alignment with the vision and the Brand Standards.
  22. After the final set of tests are run, the UCD Designer and the Writer(s) are released from the project. Elevation usually takes place without Design’s participation because if it’s a Design issue at that point, it’s too damn late.

And then it’s done. It only took a Usability Engineer, two kinds of Writers, an Information Architect, an Information Designer, an Interaction Designer, a UCD Designer, and all of the design support roles (design managers, brand managers, marketers, photographers, code component builders, usability test recruiters and schedulers, etc.) to handle the design tasks. Also, approximately seven to twenty other people to do the business and development tasks. Quite probably more when vacations, short-term leave, and job changes are factored in.

In contrast, I’ve also been on teams where, for a given project, we had a business person making the request (but no product owner or business lead), myself playing the role of UX Designer (encompassing IA, Writer, ID, and IXD), a scrum master (who had two other teams), a developer, a BSA who doubled as the SAT and CAT tester, and a Usability Engineer on call when we needed them. Five people on average.

Nobody in their right mind would prefer the super-bureaucratic version of this design process — unless they needed the ability to swap out designers and developers at the drop of the hat, and then redundancy is a very valuable thing.

The risk is that fragmentation of roles and skills can be so incredibly prolific that a “small team” approach to design and development becomes impossible. “Pivoting” from one design or development solution to another also becomes increasingly difficult and expensive.

And yet… that doesn’t mean the software doesn’t ship. Because for every hat the designer takes off, that’s one less piece of work the designer has to do. Fewer roles means less shifting of context, and some efficiency is gained. Some roles, like Writer or Information Designer can be spread across multiple projects, because their skills aren’t needed on a daily basis, and may only be required for a few weeks of a six month or two year project.

The lynchpin is communication. The larger the team, the more time is lost to the overhead of keeping everyone on the same page. On the other hand, the smaller the team, the more skills are lost if one member is a poor communicator, falls ill, or leaves the team. One lousy communicator on a team of four is significantly more dangerous than one lousy communicator on a team of twenty.

Specializing is incredibly valuable if there’s a specific role that a person loves to fill, or a specific role that an organization needs to have handled. I love information architecture and I prefer having as few other roles as possible layered on top of it. As a specialist, I get to spend the vast majority of my time on my favorite tasks and only dip into the others when called upon to do so.

On the other hand, I agree with Jared Spool that compartmentalizing, or only having experience in on area is dangerously unproductive. Even on stupidly large teams and stupidly long projects, an overlap of skills between the different designers (and even the developers and business people) ensures efficiency when someone’s on vacation or away or new.

So to anyone who’s concerned about working for a company that requires specialization, I say don’t worry. Working as a specialist means getting the opportunity to gain a deep understanding of one kind of Design. It means being exposed to specialists in other fields, which makes it it’s a great way to learn a lot without being held responsible for everything. Finally, it means the opportunity to move from one specialty role to another, providing a fresh view of design every few years.

But, y’know, if you can encourage your organization not to specialize to the point of ridiculous, that’s a good idea too.