IA in Complex Business Context Portal
•Télécharger en tant que PPTX, PDF•
3 j'aime•1,625 vues
"IA in a Complex Business Context" was presented at the 2015 IA Summit in Minneapolis, Minnesota. If you were at the talk and want to give feedback, you can rate it at SpeakerRate. I'd also love your feedback, find me on Twitter at @Documentalope. Find the full transcript at: http://sarahrbarrett.com/work/ia-summit-ia-complex-business-context/
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (9)
En vedette
En vedette (20)
Similaire à IA in Complex Business Context Portal
Similaire à IA in Complex Business Context Portal (20)
Dernier
Dernier (20)
IA in Complex Business Context Portal
- 1. IA in a Complex Business Context Sarah Barrett, IA Summit 2015
- 2. Why a “complex” business context?
- 3. Process, not personality. When the business gets complex, your process needs to pull its weight.
- 4. The project: - Internal portal for underwriters at a personal insurance company. - Replatforming, partnered with SharePoint specialists.
- 5. Underwriting 101: 1) Evaluate new policies. 2) Evaluate claims on existing policies.
- 6. Interviewing experts. You’ll make mistakes. Your job is to avoid doubling down on them.
- 7. Let yourself learn. You never know what’s going to be interesting, make sure you don’t box yourself in.
- 8. Phase One Prototype Not where we wanted to be.
- 9. Navigation Model More user-centered and reflective of a dynamic content environment than a site map.
- 10. First define what goes on a page,
- 11. Then decide what’s important.
- 12. Limit your variables. Build to complexity while maintaining understanding by defining one thing at a time.
- 13. Phase Two Prototype Much better, but don’t get married to design.
- 14. Specificity without fidelity. The relationship with developers is delicate. Use your stories.
- 15. Success? "First day, it’s already come in handy. Had to find something and was able to quickly get the process and check the regulations.” "The site is also pretty neat since I can find quirks I didn’t really know about."
Notes de l'éditeur
- I’m going to tell you a story about some things I regret, which I’m pretty sure is the opposite of what I’m supposed to do up here, but I’m also going to tell you about how I turned a lot of those things I regret into one of the projects I’m most proud of. It’s not flashy, or sexy, but it’s exactly about why IA makes a difference, and why we do what we do.
- IA in a complex business context. Why “complex”? Because when it’s simple, you can get away with a lot. You can rely on just doing good work and being a generally lovely person, and your process doesn’t have to do any heavy lifting.
- A lot of the advice I’ve found around getting to consensus and talking about design is about personality, or rather, what you can do as a person to ease the process. Modulate your tones, ask the clients about their weekend, smile at people. And, you know, yeah, by all means do this, be a normal pleasant person. Even cultivate charisma and charm if you want to, but it’s process, not personality, that gets you to successful outcomes.
- I’m a partner at Factor, a Seattle-based consulting firm that specializes in designing information and experiences. As a consulting firm, we work with all types of clients. When a UX team from an e-commerce site brings us in, our process needs to make sure we do good work in a timely and efficient matter, but everybody’s going to get it, we’re all from the same world. When the business gets complex, though, it needs to do a lot more. In the Fall of 2013, we started work on a project replatforming an internal portal to Sharepoint 2013, with an implementation partner. This portal had over a thousand documents that needed to be routinely accessed, was where nearly everybody in the underwriting group of a personal insurance company spent their entire work days, and was managed entirely manually, in Microsoft Frontpage. For reference, the most recent version of Frontpage is from 2003. 2003 was a long time ago. Mel Gibson won a People’s Choice award in 2003. Things have changed a bit.
- To make it much simpler than it is, most of what underwriters do is evaluate policies and claims to see if they’re in line with what the company wants to do. This is nearly 100% about finding the information that applies to a particular case and making a judgement call about how to apply it. When you’re doing that for 8 hours a day, IA matters a lot, and in Sharepoint, it’s all the control you have.
- We try to be rigorous in our research, and I believe in that, but with larger cohorts and more formal presentations, our original process let us make mistakes without realizing precisely why they had happened. I made mistakes in the interviewing without realizing because we were dealing with experts who lived and breathed this information. I could pay as close attention as possible, but doing fifteen interviews one after the other wasn’t giving me a chance to really learn what was happening. “Action,” for instance, is a word that can easily come up in research. “Do you want me to click on this?” one participant asked, as she showed me something, and I said, as I normally would, “Just take any action, do anything you…” And she stopped short: “Action? No, I couldn’t take action here, in order for that, I’d need to…” and no matter what I did, she was stuck on that, because in the insurance world, an “action” is a very specific thing you do to a claim, and it’s fraught with regulations. That was one I was able to figure out, but a lot of these things were subtler. We realized that we needed to switch up our research so we weren’t doubling down on our mistakes. We made our user research process more iterative. Instead of doing interviews with a block of fifteen participants and trying to ask them all consistent questions, we split it up into multiple rounds, and regrouped after each one with the business stakeholders to go over the results and have them help explain to us how the participants’ ideas interacted with the business realities. This process let us learn a lot about their business very quickly. We also improved the kinds of questions we were able to ask: Instead of just asking somebody to complete a task for us, we were able to ask them specifics about why. “So, I noticed you searched by line of business for a policy about a new car. If it was, say, from 1960, but was somebody’s primary vehicle, how would that change? Is that different in California?” This is all so intuitive to experts that they can’t explain all the caveats and pieces of information they take in to make these decisions. You have to figure out enough to ask about it.
- Let yourself learn. Even though learning is a thing we all say we want to do, it’s really easy for a process to box you into decisions quickly. Doing the research iteratively this way let us make lots of very low stakes mistakes, and gave us a chance to build a shared vocabulary with the clients that was primarily theirs. We didn’t make them learn about mental models, we learned about insurance. We got our clients go through each round of research questions with us, and answer them as the participants would. This mini iteration on top of each larger one let us recognize where leadership varied from the end users when we were in the real interviews, and made us better able to recognize the good stories and really useful findings. In one meeting, after we switched it up, I asked a clarifying question, and one of our clients turned to the other and, laughing, said “They speak insurance!” and then, most importantly of all, proceeded to give us the information we really needed.
- We went ahead, according to plan, which called for us to go from research, to a sitemap, to a first draft of a prototype. We had lots of great information about our users, and were on schedule, so far so good. This prototype was absolutely excruciating to work on. It was clear that even though we had good information about users, we were making tons of decisions all at once. Granted, these were decisions based on intuition and best practices, but my concerns were borne out when we presented it to the clients. Presenting it was an awful feeling, and nobody reacted negatively, but they did start asking questions and proposing things that seemed totally out of left field. They brought up things we thought had been decided, they got caught up in the details, and the entire discussion became derailed. But it got approved. We were charming and persuasive and articulate about our “vision,” and at the end of the meeting, the clients were smiling. But that didn’t make it right. It was obvious to us that we couldn’t double down on what we’d done already, so we hit the brakes to figure out what the problem was. Even though our research was great, we’d built up a lot of empathy for the users, and we had a bag full of great examples to reach into, we’d made too many design decisions at once, and no amount of explaining or charisma was ever going to make the clients understand what we had done. They might agree in the end, but they’d never understand. So we went back and added some deliverables to make sure we were doing one thing at a time and involving our stakeholders in major decisions. We added a navigation model, to complement the site map, because it was more reflective of the dynamic content environment and user paths, and page description diagrams, sort of verbal wireframes, so we were separating out what the navigation needed to be able to do from how we were going to do it. Separating What’s on a page from What’s important and then finally how we communicate that importance.
- Limit your variables. For your project, figure out how to make sure you’re designing one variable at a time. You can’t solve for X when you have five other variables, and you can’t get non-designers on board when you design too many things at a time. What your variables are and how you’ll limit them depends on what your project needs, but I encourage you to think about what each deliverable, each step of your process is trying to do, trying to get out of your stakeholders, and try to keep each step narrow. This gets the best feedback out of clients and keeps things approved because it actually educates them, rather than just convinces them. You may not end up where you thought you would, but that’s great. You’ll learn more, and everybody will know why things are happening. The real magic of this is that your stakeholders will know and remember what is happening and why, because they understand it, and they can explain it to other people when you’re not around. In IA, a good explanation is evangelism.
- So, we knew our users, our business stakeholders were with us, and we were in the thick of back end implementation, starting detailed prototyping on schedule. We began prototyping again, and this time, it was a completely different experience. There was precedent that we had all agreed on —while knowing what we’d agreed on— that all created solid ground to design on. One problem: We still had to get our partners, the implementers, on board with the prototype. How many times have you had a developer look at a prototype and started with the things that are flatly impossible? When that happened with our second-round prototype, where I knew our decisions were solid and the client was on board, my adrenaline started going, and I got ready to debate our points and argue for it, before I caught myself. That might “win” but it wouldn’t improve the end product. Instead, we did our best to be aggressively cooperative, and put the focus onto the precedent that everybody had already decided, instead of the last design decision we had made. “We can’t have that kind of modal, because it requires Sharepoint to be integrated with Office365, and that’s not on the roadmap.” *cue everybody going into a lengthy debate over whether it should be on the roadmap, which is wildly out of scope and frankly, I don’t care at all about, I was just getting things from the documentation.* Instead of arguing for the merits of the design, we would fall back to what our real goals were. “Excellent, the modal is dead. Users need to be able to quickly see where a document came from and who approved it, so they can decide whether or not to use it. We just need it to be associated with the documents when they come across them.” “So, if you want to add more more of these metadata links to an item, we’re going to have to define additional templates for that.” “We don’t need it to be clickable or linked, just visible. It sounds like that makes things simpler, what else do we need to define now?” This was a point we were able to fall back to quickly, without giving anything up, because we knew that provenance was vital for our users. It didn’t matter whether it popped up or was visible all the time, those were small details that could be ironed out. We really needed was for them to be able to see that metadata and use it to make decisions. That precedent let us let go of the fidelity you can’t help but get to in design, and get to the specificity of the experience.
- Specificity is the soul of narrative. Use the specifics you know, and that everybody understands, to tell the narrative of the required experience without getting attached to solutions. It’s easy to fall into debating, as if you’re trying to persuade some third party, like the client. Instead, speak to be understood, tell a story. Users need to know about provenance to be able to make decisions about whether or not they can base an opinion on a document. There are nine ways to do that, at least. Don’t assume you’ve always designed the best one.
- And in the end? It was a success, by any measure you care to name, I think. I didn’t know that at first, all I knew was that we’d done work that was implementable and I was proud of. When you’re consulting, that’s how it goes sometimes, you just walk away at the end of a project and hope it goes well. But months later, the client forwarded us the flood of excited messages he had gotten when the new site rolled out. Without changing the content in any significant way, in the first week, the first day, users were reporting that they had found information that they had never seen before. In this site they’ve been living in for years. Brad, our primary stakeholder, also reported being tackled with hugs. In the office hallway. Of an insurance company. Because of an intranet. The upside of what I’m telling you here is that. The downside is that no one will ever be amazed at what you came up with. You won’t seem like a guru or a genius. In this kind of process, everything you do should seem like an obvious choice.
- Personality might do that. You might be charming enough or persuasive enough. I think if we hadn’t changed anything, the client would have still loved us. But he wouldn’t have gotten hugged in the hallway. Our personalities didn’t do that, the process did. Thank you.