IA Summit 2015 Main Conference Talk
Topic(s): case studies, enterprise, and user research
How do you address user goals when your users seem to speak a language of their own? How do you stand up for users when developers dominate the process? How do you engage stakeholders to turn them into evangelists? How do you make sure everyone really understands and agrees on what you’re doing
In this talk, you’ll see how we rescued a project that was about to go off the rails and in doing so, answered all these questions and more. It will leave you with specific, actionable advice, illustrated with examples from this project, about how to get to meaningful consensus in a project and develop, test, and socialize your IA deliverables.
- How to plan user research to quickly master a complex business context and socialize the project before it’s even finished.
- The importance of designing and testing one thing at a time, and how to structure your deliverables to do it.
- Strategies to get to meaningful consensus that are about process, not personalities.
About the speaker(s)
Sarah Barrett is an information architect and UX designer specializing in enterprise information architecture, contextual inquiry techniques, and integrating user centered design methods with information modeling and taxonomy activities. She’s worked with many enterprise clients, including Amazon, Adobe, Microsoft, Safeco/Liberty Mutual, Expedia, and Pearson.
Sarah has also spoken about UX, user adoption, IA project techniques, and user research at national conferences like the IA Summit, the Special Libraries Association Annual Meeting, Taxonomy Boot Camp, and ConveyUX.
Sarah Barrett: Hello. I’m going to talk to you about regrets, and some things that I regret, which I recognize is kind of the opposite of what you’re supposed to do up here.
I think this is the space for the “My Fabulous Career” talks…
Sarah: …but I want to talk to you about those regrets because we managed to fix a lot of those things that went wrong. It managed to turn this project into one of the things I’ve worked on that I’m really most proud of.
It’s not flashy or sexy, but it does get at why IA matters, and why it is we all do what we do.
Why a complex business context? Basically, when it’s simple, you can get away with a lot.
When you understand the business and the client understands the design, you can get away with just doing high-quality work and being a generally lovely person, and it’ll all work out. That’s not as true when the business gets complex.
When I started doing research for this, I started looking at a lot of advice about how to manage difficult projects and how to work with clients, and that kind of thing. A lot of the advice is about personality, what you as a person can do to ease a project.
So, [laughs] a lot of this advice is stuff like, “Smile at people. Ask your clients about their weekend. Modulate your tones.”
Please, yes. Do all of those things. Act like a normal pleasant person. That’s a good idea.
Sarah: Even if you want to, as I’ve seen advised, go out of your way to cultivate charm and charisma. I think that that is all fine, but that’s not what gets you to successful outcomes. Process does.
In the fall of 2013, I started working on a project where we really needed that process to work for us. It was for an internal portal for a personal insurance company that was used all day, every day by the underwriters at that company to find the information they needed to do their jobs.
Our IA work was part of a larger re-platforming. We were partnered with some SharePoint specialists. We’re moving to SharePoint 2013.
The experience they had, even though everybody had to use it all day, was really difficult to use, impossible to find anything, and horribly difficult to manage. It was one person’s job.
Poor Brad. It was his entire job, even though it wasn’t supposed to be. It was maintained entirely by hand and static pages, which is one of the reasons it was so awful.
It was an entire FrontPage. I actually had to go look this up. The most recent version of FrontPage is from 2003. 2003 was a really long time ago. Mel Gibson won a People’s Choice Award in 2003.
Sarah: So things have changed since then, but the site hadn’t. It has just gotten bigger, messier, and made poor Brad’s life worse each day. So, [laughs] we really needed to help them.
A little bit of underwriting 101 for those of you who don’t know. I didn’t, when I started the project, most of what underwriters do, and this is a gross oversimplification, but a lot of what they do is figure out whether new policies the company is going to write are in line with all of the rules and guidelines.
Does the driver for the auto insurance policy have a good record? If it’s a home insurance policy, does the pool have the right kind of fence around it?
Then once claims are made on those policies, they make sure that the claims are all above-board, and, again, within the lines. Really when you think about it, both of those tasks are almost 100 percent about finding the right information and figuring out whether it applies to your situation.
When you’re doing that in an interface for eight hours a day, IA matters a lot. When you’re working in a pretty native SharePoint environment, it’s kind of all you have.
We got going on our project, and we started it with user research. We really pride ourselves on our rigorous user research process. I do believe in that, but a thing we noticed pretty early on is that all the rigor of that process was actually letting us make mistakes without realizing why they had happened.
We were doing a large cohort, trying to ask them very consistent questions, and doing a more formal presentation after it. That was letting us miss things, because we were talking to experts.
The underwriters spent their entire day doing this. They really knew their business, and they did not speak our language. They spoke their own language that had nothing to do with us.
Doing 15 hour-long interviews, one after the other, after the other wasn’t giving us the chance to regroup, figure out where we messed up, and try and figure out how to fix it. One example, the word “action” is a word that can really easily come up in user research.
Somebody’s looking at a page, and they say, “Oh. What do you want me to do? Do you want me to click on this?” You say, “Just do whatever you normally would. Take any action you want.”
In this case, they would stop short. They would say, “Action? I couldn’t take an action here. If I want to take an action, I’d have to,” and they would be off.
Sarah: It was really hard to pull them back and actually have the rest of that interview happen. Turns out, didn’t know this, action has a really specific meaning in insurance. There’s all kinds of regulations around it.
We couldn’t use that word without disrupting the entire interview. That was lucky, because that was one of the ones that we saw right away.
There were lots of subtler mistakes that I realized later where we just hadn’t gotten information. We didn’t know what they were telling us because we didn’t have that context.
In order to fix this, what we decided to do was make our process more iterative. Instead of doing one big block of user research, we did several smaller blocks, fewer participants, and regrouped with the client, with Brad, [laughs] after each one of those.
Went over what we had asked. Went over what we had found. Asked all of our stupid questions, and got them out of the way. Because we’d only talked to a few people, it was still all right. We hadn’t built too much on it.
Then we made him and his colleagues go through and answer the questions that we were going to ask the next set of participants again, get that language, get all those stupid questions out of the way. This let us learn a lot about their language and their business really quickly.
It also, very importantly for this kind of user whether it’s insurance or not, let us ask much better questions because we could get really specific. We knew their language. We knew their business. We knew what was important.
Instead of just saying, “It looks like one of your tasks it to find information about an auto-policy. Show me how you would do that,” we could watch them and say, “Oh. I noticed for a new car you looked by line of business first. How would that change if the car was from 1960?”
“All right, what if it wasn’t kept in a garage, but was somebody’s primary vehicle? Is that different in California?” We knew that those things mattered to them, and we could get at those little nuances that we needed to really make the IA work.
It’s important to remember, [laughs] that experts can’t explain all the things that make their process. So then they can’t see that forest. You have to know how to ask about the trees.
We all say we want to learn in our process, but it’s really easy to get boxed in by decisions you make really early. This kind of iteration lets you make those small mistakes without ignoring them and letting them turn into large mistakes.
Also, working with the client in this kind of iterative way makes the process theirs as much as its yours. It lets you build the shared vocabulary around what you’re doing and why.
I think the key to a shared vocabulary that gets ignored sometimes is that, especially with non-designers, the vocabulary has to be theirs, not yours. We didn’t make them learn about mental models. We learned about insurance.
In one meeting, after we had rejiggered this process, and learned a lot more about what they were doing, I asked Brad a clarifying question about something. His first response was to laugh, which is a little bit disconcerting. [laughs]
Then he turned to one of his colleagues and said, “They speak insurance,” which was very flattering. The really great part was then he turned back and gave me exactly the information I needed to move forward, and we could understand it.
We started prototyping, which was the next step in our process. This user research, the technical stakeholders, the SharePoint architect put together a site map, and we were going to prototype about it.
This was excruciating to work on. [laughs] It’s one of the worse things I’ve ever had to do.
It was really because the path forward wasn’t clear. I didn’t know what we were supposed to be doing really, and I didn’t feel confident in any decision I was making.
Presenting it was a terrible feeling for a perfectionist like me. It was interesting because the client didn’t react negatively in of those ways you might expect. They didn’t reject it. They didn’t get angry.
They did all of those other things that are really good signs of a client rejecting a deliverable. They started asking questions that had nothing to do with this. They started proposing solutions that had nothing to do with the deliverable at hand.
Things that we thought had been approved weeks ago came back up. All of those things that derail a meeting mean a client’s not on board, and all of that happened here. But, it got approved.
We did all of the things we were supposed to do. We were articulate. We talked about our vision and where it was going, and our design rational.
At the end of that meeting, the deliverable was approved. The client was smiling, but that didn’t make it right.
We needed to stop, so we hit the brakes. We tried to figure out what we had done wrong. What was wrong with our process?
We decided we had done too much at once. So, we retooled our process to make sure that we were designing one thing at a time.
We realized the client might agree, but they were never going to understand what we had done and why. That was just going to cause us more problems later on.
We added some deliverables. One of them was a navigation model which separates out how a user wants to be able to navigate from how that’s going to happen.
We know users need to navigate by state. That can happen through contextual content. That can happen through a clickable map. That can happen through tappable navigation.
We’re staying agnostic at that point. That goes to finding the prototype. We’re just going to decide what the user needs to do now. We’re all going to agree on that.
We also added page description diagrams, which are like a verbal wire frame. First you define what goes on a page, and then you decide what’s important.
The key in all of this is really to do one thing at a time. You can’t solve for x when you have five other variables muddying the waters. You’re never going to get non-designers on board when you’re designing five things at once.
I think the variables are different for each project. This is what they were for this one, but I would urge you to take a little bit of time.
Think in your process what the goal of each deliverable is. What variable are you defining here? Try and keep it narrow.
I find this gets the best feedback out of your stakeholders, out of your clients, because they actually understand. It keeps things approved. They don’t come back up in later meetings because you’re educating them about the process and the project. It’s theirs too, instead of just convincing them.
The real magic of this I find, actually, is that the client understands it. So, they can go out and explain it in their own words when you’re not around.
They can go talk to their boss, their employees, their colleagues, and give their explanation in their own words, which is almost invariably going to be better than your explanation for those people. In IA, a good explanation is basically evangelism.
Phase two prototype. This felt completely different to work on. We had all of this shared precedent to build on, and I really knew what we were doing. It was really fun to design even though it was huge amount of work.
There’s one problem. Our partners, the SharePoint implementers, were not yet on board. They did not yet completely trust us, I think.
How many times have you presented a wire frame or a prototype to a developer and had them start with the five tiny details that are just flatly impossible? How they won’t do that?
That happens to me. [laughs] It’s always frustrating, but when it happened here where I knew our design decisions were solid, I knew the client was on board, and we were really together on all of it, it was awful.
I immediately started wanting to fight for my design. My adrenaline got up, and I started wanting to argue, go into that meeting and really win it.
I had to make myself take a step back. We had to figure out how we really wanted to handle this, and what our strategy was going to be. That might win, but it wasn’t going to get us to a better final product.
We rethought how we wanted to handle this. The strategy we settled on is a kind of aggressive cooperation.
So, you don’t let the developers do whatever they want and walk all over you, but also don’t stay too tied to the last thing that you design. Be tough on the precedent and the user goals that you’ve decided, not the last design decision.
When it happened that I’d put something in the prototype and the developer took one look at it, “Oh. We can’t design that kind of Modal because that requires integration with Office 365, dah, dah, dah, dah.”
“OK. Great. Modal’s dead. What I really need, what we really need is for users to be able to see information about where the document came from, who approved it and when every time the document shows up. How do we make that happen?”
“Well, if you want that to be interactive we have to…”
“OK. Doesn’t have to be interactive. All I need is that to show up every single time it gets used. It sounds like that’s a lot simpler. How do we make that happen? What do I need to define for you right now so we can have that happen?”
You can do that without actually giving anything up, because you know what’s important. You know your precedent is.
We decided that users really need to know about provenance. They need to know where these documents came from. There are probably 15 ways to make that happen. Don’t always assume that you’ve designed the best one.
Specificity is the soul of narrative. Use what you know about the specifics of an experience to tell a story. Tell that story of the user journey, the user goals. Use that to talk to your developers while staying as agnostic on the solution as you can.
I think it’s really easy to get into a mode of debate, especially when your design is on the line. You know we invest ourselves in these things. It’s really easy to start trying to score points from someone else, or put one over on them, or get the client on your side like you’re persuading some third party and participating in that kind of thing.
I would really urge you to try to take a step back and not do that, whether you’re talking to a client or a technical stakeholder, whoever you’re working with. Instead, and this is a subtle difference, but really try to speak to be understood rather than to win. Tell a story. It will work a lot better.
So, how’d it go? It was a success, I think, by any measure I can come up with. I didn’t know that at first. I knew that I delivered work that I was proud of. The client was happy with it. It was implementable by work consultants. At the end of a project, you just walk away a lot of time and you don’t know what happens.
It wasn’t until a few months later, when we were actually reaching out to Brad asking for a reference for another project that he forwarded a bunch of the emails he had gotten the first week the site rolled out. These are some of them.
Without changing the content at all, we reorganized it. We applied new metadata. We moved it into a new site without changing the content. In the first week, in the first day people were able to find information that had been eluding them for years, in the site that they were intimately familiar with.
This also doesn’t include the little addendum that Brad put on the email [laughs] which is also that he had gotten tackled in the hallway, of getting hugged by underwriters who were so excited about the new SharePoint. [laughs] Which I’ve never heard of before, it’s pretty gratifying.
The upside of this is all of that. That kind of success is where you can get with this kind of discipline and this kind of focus on your process at the expense of your ego, quite frankly.
The downside is that no one’s going to be amazed by anything that you do. No one’s going to think you’re a genius or that you’ve come up with some brilliant new thing or be surprised by anything that you’ve come up with.
If you do this right, every decision you make, everything you come up with should seem inevitable. It should seem obvious and reasonable, and, “Oh, isn’t this where we should have been all along?” That’s a trade-off that I think is worth it. You have to decide.
Personality will get you some of the way there. You might be persuasive enough and charming enough. Your idea for this end product that you come up with, it might be good. What you end up with might be great.
I think if we hadn’t changed anything, if we had just stuck with our original process, Brad would still have loved us. We got along very well. The underwriters would have been happier. It was always going to be better than what they had started off with, but somebody who wasn’t involved in the project wouldn’t have hugged Brad in the hallway.
Personality didn’t do that, process did. Thank you.