Information Architect – Page 2 – Perpendicular Angel Design

14 February 2015

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.)

Someone gets an idea, which makes it to the business folks with enough authority to decide it’s worth funding.
The Product Owner writes a Project Charter, passes it through some sort of complex and magical bureaucracy, resulting in a Budget for a Project.
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.
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.
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.
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.
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.
The IA puts together the Design Vision Plan so that IT knows when they’ll be engaged for development.
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.
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.
The IA completes the wireframes in Visio and passes them on to the ID.
The ID “skins” the wireframes in Photoshop.
The IA, Business Lead, and Product Owner present the current state of the project at an Executive Review. The IA facilitates dispositioning the feedback.
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.
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.
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.
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.
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.
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.
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.
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.
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.

1 April 201413 April 2016

How to get from strategy to measurement: the capability strategy sheet

I just came from a great first day of the An Event Apart conference in Seattle and I am both extremely inspired and motivated, and a little flustered.

I blame Jared Spool.

Jared is a) a great guy, b) a masterful speaker, and c) a wonderful source of information and thinking around the web, it’s strategy, what work, and what doesn’t. If I’m going to be irritated by something (and in this case I mean it’s like a brain itch, not like angry) then I’m glad it’s Jared’s talk that’s irritating me.

Jared’s talk today was about the importance of UX strategy to business, and the importance of business strategy to the success of being a UX designer.

During his talk, Jared explained that design is the rendering of intent. Business models are the intent of the business, and most business models can be mapped to one of five categories.

He gave a bunch of great examples of how various elements of companies’ designs (or experiences) mapped back to positive changes to their business strategies. It’s all very good and I’m not going to even try to replicate it here — go see Jared give the talk if you want the details.

So here’s the problem: he used Vanguard’s website’s content and videos about investing and the market as an example of something that couldn’t be mapped back to business strategy. That irritated me because, well, I work at Vanguard, and I often forget that not everyone has seen the way that we work.

See, we have a strong definition of character and values that is built into everything that we do and don’t do. That set of values has, since the beginning, shaped our principles for investing success. There are lots of ways that these values map back to the content on our website, but the biggest (to me) is through education. Smarter investors are better investors. We’re so confident in our investing principles that we actively teach those principles to our investors, so that whether they’re with us or someone else, they’ll be more successful investors.

After Jared’s talk I asked him if he really didn’t know the connection between the content and the business strategies, and explained it to him. He asked, “Yes, but how do you know it works?”

Well, the fact is that I don’t know that the specific article and the specific video that Jared screen snapped work in a measurable. Nor do I know for sure that we’re always eating our own dog food when it comes to design (or how much Legal would let me tell you about that dog food.)

I can, however, tell you about a tool that my then-manager at Vanguard Richard Dalton taught me to use in 2010/2011 called a capability strategy sheet. It connects the dots between the business goals, the user needs, and whether they’re working. It makes user experience measurable.

Here’s a quick run-down of how I use capability strategy sheets on most of my projects as an Information Architect and Generalized Troublemaker.

1. Sit down with the business and learn everything then can tell me about their business goals for a specific capability they want us (the UX team) to help them design.

2. Using a combination of personas and user research we already have in UX, and user research the business has done (which they needed to get funding for the project or they wouldn’t be talking to me), we document our understanding of who the audience/customer/client is and what their goals are.

3. Write down the two lists, then, with the business, prioritize the goals into one giant list. (This step contains a lot of reminders that if all the business goals lead, then no one visits the website, which is amazingly effective especially when you can back it with data from previously failed projects. Keep all your data all the time.)

4. Talk about the client’s environment – inside and outside of their head – for each goal. Are they knowledgable? Frustrated? Afraid? Do they trust you? To be honest, this is the one step I’m most likely to skip, because strong emotions aren’t linked to many of my projects. Still, it’s good to ask yourself if it’s needed before you throw it out.

5. Talk about the current approach and the ideal approach to meet each of these goals. Is there a current approach? Does anyone know how to reach a better approach? These are first passes and we iterate on them a lot both at the strategy level and when we start making detailed screens.

6. Write down the success criteria. This is the critical one. Write down what piece of measurement you can do to see if your design worked. For example, if the client’s goal is to recover a password and the company’s goal is to help the client recover the password without calling, then when the new “recover your password” capability launches, visits to that area should go up, and the number of phone calls should go down.

Sometimes the measurements are easy to map to the capability – call volumes go down. Visits go up. Some times they’re harder to gather. “We should see the complexity of our calls rise because the simple calls won’t come into the call center anymore.” Lots of data needed from the phone teams for that one. Sometimes they’re downright esoteric — did trust go up? You need a good survey (a great usability engineer can help you with that) which will measure trust before and after the launch of a product. And hope that no one blows up some other capability that causes people to lose trust while you’re busy trying to build it.

Map all of it to a giant spreadsheet. Shop it around, get the important people to agree with it. If possible, help them own it. We’re all in it together. These are the things that matter about this capability, and these are the ways we measure whether we’re reaching those goals.

Then, while your starting your wireframes and your personas and all your other deliverables, take your baseline measurements. Or ask your business to take the baseline measurements. Or ask the business to all the business intelligence area to take the baseline measurements. Measure before you cut.

When your project is done and your stakeholders are asking “how do you know if it worked?” (Especially that one that was kind of doubtful you’d pull it off), measure again. Compare the results, disposition the feedback, and know how we you did both as a design organization and as a business.

There are three results to this process.

The first is that when you’re done, when Jared Spool asks whether you can measure the success of your content, you know you can go back to the office and pull the capability strategy sheet for that project, run some measurements, compare them to the baseline, and see if in fact, the capability of serving content in this area of the site that educates the users about this specific thing is working. (I’m not going to, but I know I can.)

If it’s not working, hey, that’s a conversation to have with the business, because their goals are no longer being met and that’s a problem.

The second result of the capability strategy sheet is that now you have a list of the goals for this capability that you and the business signed off on. You have (limited) persona information, the business’s approach, and dashboard metrics all documented in one place.

Six months or six years later when someone comes to you and says, “we want to enhance Capability X to add this thing” you can pull your capability strategy sheet and start the conversation there. “The last time we worked on this, here were our users and goals. Tell me about how your new enhancement fits in with these goals.”

When we start enhancement request with an understanding of the current application’s goals, we help the business remember why we built what we built the first time, and decide whether their Shiny New Thing is better or worse, more or less important, than the rest of that capability. This can help discussions around positioning, priority… It keeps the project team aligned with the culture and philosophy of our company (or helps us change if we’re off course). One memorable time it even resulted in the canceling of a Shiny New Thing that was a Really Bad Idea in light of the existing business strategy and principles.

The third result is that you build up a portfolio of projects as a design group that have actual measurements attached to them. You will have the tools to say to a new stakeholder, “I know this seems like a lot of strategy when all you want is for us to “make it pretty” but here’s the revenue growth / cost savings / measurable results we received from following this process.” It’s easier to achieve buy-in to UX being an effective approach to problem solving when you can measure it.

So, to sum up: yes, business strategy is critically important to design – and design to achieving business strategy, as Jared pointed out today. And it’s not enough to just say, “this content achieves this goal”, you have to be able to prove it. That means you have to be able to measure it. Jared’s talk today emphasized the need, but not the technique, for accomplishing that goal. Richard Dalton’s Capability Strategy Sheets are one tool to move from understanding the business strategy to implementing it in a measurable, and ultimately successful, way.