Sharepoint in a Complex Business Context

Presented at SharePoint Symposium 2015

Through the lens of a case study for a highly successful transition to Sharepoint 2013, this talk will give attendees a framework for integrating UX techniques into an Agile Sharepoint process. Relying on best practices and industry standards works well in a relatively simple business context, but when a business gets more complex, it’s vitally important to make sure the design process is iterative, that deliverables are structured to get meaningful consensus, and that business, design, and technical stakeholders can agree on functionality and priorities. The case study will take you through a project that was going off the rails, and how it was pulled back into a success that eventually led to users tackling the project sponsor with hugs. It will share what we did right, what we did wrong, and what we learned along the way to make every Agile Sharepoint project more successful.

Deck

Resources

Transcript

I want to talk to you today about some things that I regret. I know that traditionally, the case study is the space for the “my fabulous career” talks, but I think discussing the places where we’ve messed up is just as important, and it is what moves us forward as a discipline. A lot of what I want to talk about today isn’t flashy or sexy, but I think it really gets at how you make these projects work.

Why are we talking about a “complex business context”? Basically, because when it’s simple, you can get away with a lot. When it’s simple, meaning you’re familiar with the business, you’re designing for amateurs, or your stakeholders understand design and implementation, you can get away with just delivering a functional solution on time and generally being your lovely self. You can start thinking about your people toward the end of the process, and they’ll still use the solution.

When it gets more complex, you can’t count on that. People actually using the solution, adoption, is the most important factor in the success of a SharePoint project. On a very real level, it doesn’t matter how functional everything is if people refuse to use it. And they do refuse sometimes. When this happens, we often hear that “users hate change.” This is a thing that people say in UX a lot. “Our look and feel refresh is fine, users just hate change.” This is false.

Users don’t hate change, they hate you. Us, really. I include myself in this. They hate us for making decisions that make their days worse, sometimes without even knowing we’ve done it. To make decisions that won’t make them hate you, you have to start thinking about adoption right away, because it takes so much more than training.

A quick digression: At the most basic level, any instance of communication looks a bit like this.

You have a sender who communicates with a receiver over a channel. With apologies to Claude Shannon, each of these stages can have friction, which Shannon called “uncertainty.” We have the opportunity to reduce friction at any of these points, that’s how you get clearer communication.

A lot of user experience work looks like this. There’s a service or product and an end user, and UX operates in the middle space, making it as frictionless as possible. To reduce friction on the other points here, you’d have service design or business consulting on one end, and then end user training on the other.

In SharePoint projects, this is often what’s going on, and we can think about reducing friction at any of these points. Looking at the literature about SharePoint adoption, a lot of it really put the responsibility on the end user, through training, and I suspect this is because they’re often employees. A captive audience. Good training is a beautiful thing, but it can’t do all the heavy lifting here.  You know, I don’t really want this to be true –my background is in librarianship, and librarians are all about teaching people to use the card catalog– but I will tell you: Design trumps training, every time.

In the fall of 2013, we started a project that showed us how true that was. I work with Factor, a consulting firm out of Seattle, and we started working on an internal portal for a large personal insurance company, which was used all day every day by the underwriters. Our work was to define the IA and user experience and was part of a larger re-platforming to SharePoint 2013, partnered with a team of SharePoint specialists. The existing experience they had was truly awful. It was difficult to use, it was impossible to find anything, and it was extremely burdensome to manage. It wasn’t supposed to be this way, but the work of managing it had become one poor guy’s entire job, because they were doing it in Microsoft Frontpage. I had to look it up, but the last version of Frontpage came out in 2003. 2003 was a long time ago. Mel Gibson won a People’s Choice Award in 3004. The world had moved on, but this portal hadn’t.

So, anything we did was going to be better for Brad, but what about the underwriters?

A little underwriting 101 for those who don’t know (and I didn’t when we started this). The two main things that underwriters need to do are to evaluate new policies to make sure they’re in line with the company’s rules –does your house have the right kind of roof? If there’s a pool, is there a fence around it? etc.– and to evaluate claims on existing policies, to make sure the claims are in line with the company’s rules –is the policy active? does it apply in this situation? Both of these are nearly 100% about finding and evaluating information. The portal they had, that Frontpage monstrosity, wasn’t working, it wasn’t letting them find this information, so people had all created their own out of band mechanisms: Outlook folders, OneNote notebooks, very long Word documents. They had been trained to use this portal, but that didn’t make it usable.

So, what were we going to do for them? Right off the bat, we did one thing right and a few things wrong. The good thing is that we did user research to figure out what direction the project should go. You usually don’t even know really what a solution needs to do until you talk to the people who will use it. But, in doing the initial few interviews, it because clear that it was not going as planned. For instance, the word “action” can come up very easily in a user interview.

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

The only good part about this was that I could tell it was happening, but there was clearly much much more that I was missing as we did these interviews. What we were doing wrong was making mistakes without having a good framework in place to correct them. I was saying the wrong thing, and the participants, while great, didn’t have enough context about the project to clarify things for me. The idea that you need to be able to fail in a constructive way shouldn’t be news to anyone, this is right at the core of what’s wrong with waterfall, but it sneaks up on you, especially in activities that don’t look like design or development.

To fix it, we paused the interviews and made our stakeholders sit down with us and answer our research questions, do the activities with us first, and we really grilled them on their answers, to pin down the details. That focus and repetition let us learn the specifics and really learn to speak their language.

Serendipitously, I think, the best way to both make these inevitable mistakes and get buy-in at the same time is to create as many experiences with your stakeholders as you can. Whatever you’re doing, make them do it with you. Get them to answer your research questions as if they were a participant, so you can really hone your vocabulary. Have them observe user interviews and take notes, to see for themselves what the people have to say. If they’re insistent about an idea, have them sketch it with you, work on the user story, etc.

Whatever the experience of figuring this thing out is, share it. How many of you are familiar with the Ikea effect? It’s this bias we have, where we think our own labor is valuable, so we have a very hard time giving or throwing our Ikea furniture away; we want to sell it. It must have worth. That works on projects, too.

I’m talking a lot about research, because I believe it’s the best way to do this, and it doesn’t have to be expensive or heavy. Four people is enough, if that’s all you can manage, and when I say “research,” I really just mean doing some interviews. Talk to your people, one at a time, in person or on the phone, and figure out what’s ruining their day.

As an aside: Doing really beautiful user interviews is an art and the kind of thing that people hone over a lifetime, and analyzing that qualitative information from them is the kind that consulting firms hang their hat on. Doing user research that is good enough to be helpful is within your reach, even if you don’t have a specialist.

I’ve done a lot of user interviews, and I think if there are any tricks, it comes down to these three things. The first is a noncommittal kind of noise, that doesn’t tell the participant that they’re right or wrong, just lets them feel heard. Mind is kind of a “huh,” but you can find your own. The second is to wait. Much longer than you think you want to. If you’re trying to get someone to talk to you, ask them your question, listen to their answer, and then don’t say anything. Count to ten. You get your best information on second seven. Lastly, as John Hodgman likes to say, “specificity is the soul of narrative.” Don’t let your participants tell you how things usually work. Make them tell you what happened last time. That’s information you can use.

For bonus points, try to make sure you talk to the people on the ground, not the people in charge. Well-meaning project sponsors will try to get you the executive this and the superstar that, and that’s sweet, but it’s not who you want. You want the people just getting by. If you do interviews, look for the emotion, look for the gut punch. Nobody had ever brought up onboarding as a business driver in our meetings, but one of our participants volunteered the fact that it took eighteen months to get a new hire up to speed. That seemed like a while to me, but underwriting is complicated, so I asked if that was to learn how to do the job, and she corrected me right away. No, it only takes three months to learn how to do things, the rest of the time was to build up their own library of resources. It wasn’t because it was hard to learn, it was because things were difficult to find. That example more than justified the entire project to everyone who heard it.

Do your research, and do it together.

So, we did our research and moved on to design, building a low-fi prototype of the user experience. And this prototype was one of the hardest things I’ve ever worked on. Every step of it just felt excruciating. Because the thing is, even the lowest fidelity prototype or wireframe is very high fidelity in many ways. You’ve made so many decisions all at once –the content, how the content is structured, what the nav needs to do, how it will work, and on and on and on. The problem as, we were deciding too much at once without having precedent to go off of. We had a lot of great information and a lot of empathy for our users, but we hadn’t codified our previous work into a set of best practices for our project, so I was interpreting all these findings from memory as I was designing.

To fix this, we added more, lighter-weight steps to decide one thing at a time and build up that precedent. If I were going to do this project again, I would make sure we had a list of best practices or design principles specific to what we had learned in this project– just saying “this not that” or things to remember. For this project, they would be things like “always show users the provenance of a document” and “users have to trust they’re getting the whole story.” I probably would also just let there be a technical prototype and not bother with one for the UX, but you live you learn. The important thing to learn here, I think, is that UX can iterate just like everything else, but it works best if you let go of your ideas about artifacts and deliverables. In this case, we went old school and used Page Description Diagrams, which are sort of like a verbal wireframe.

They’re simple worksheets where first, you just figure out what goes on a page, before you visually decide how to communicate that importance.

It is vital to take these small steps, because what a “good” experience is changes completely depending on who you’re designing for. If you’re designing for financial traders who are on at least one phone all the time and still use handsets –I don’t know why, but they do– you want to make sure they have to type as little as possible, so it’s all about the mouse, and they never have to use both hands. If you’re designing for analysts at the same firm, who are all excel whizzes, you want to make it all keyboard, as little mouse as possible, because that’s how they’re used to working. As you work, think about capturing and iterating on basic principles like this. Clicks over typing. As you go, these can get more complex and more specific.

To make these successful, think of these precedents as goals, priorities, and ideas, rather than as design requirements or a backlog. One bonus is, building something as complex as a SharePoint solution, or even a comprehensive information architecture, through simple steps like this, establishing that precedent step by step, is really what allows stakeholders to understand what has happened and why. And the real magic here is that they can go talk about it when you’re not around. They’ll probably even do a better job of it than you would, because they can user their own words and examples. In this kind of major change, a good explanation is basically evangelism.

I’ll admit, though, getting there can be tough. When we started the project, one of the developers warned me that one stakeholder was a real “concrete thinker” and wasn’t going to get anything we were doing. And he wasn’t wrong. Every approval was a minefield and her confusion and, honestly, very real panic over not understanding was contagious. As a result, the implementation team also got nervous and started jumping on every perceived weakness in our work, which in turn made us defensive and less willing to rethink anything we’d done. But, as with so many things, the issue wasn’t the issue. The thing that would upset our supposedly concrete thinker wasn’t the issue, it was the fact that from the very beginning, we didn’t think the client would be able to really understand what we were doing, so we weren’t trying to get her to understand, we were just trying to get her to agree. As we worked and talked, we were trying to convince the client and our partner, not actually trying to communicate and get to a better, mutually-agreeable solution.

This didn’t have a complex procedural solution or any deliverables associated with it. I just shifted my priorities as I was talking. How were the users going to understand the experience if I couldn’t explain the ideas behind it to their boss? How were the implementers going to build the experience if they didn’t own it as much as I did? I had to make it about the challenges we were jointly attacking, not my own desire to be right.

People who do what we do tend to be passionate, which is great. That’s actually one of the things I like best about agile, is that it really reintroduces the idea of ownership and craftsmanship to digital work, rather than someone lobbing requirements at you, but watch how that passion makes you speak. It’s very easy to fall into a pattern of debate, like there’s some third party who’s allotting points for you getting one over on your opponent. And I get it, it feels great, you get to leave a meeting feeling like Don Draper. But even if you’re temporarily on top, that doesn’t get you to the best answers or keep decisions made. I encourage you, try to speak to be understood, not to win.

And in the end? I think it was a success, by many metrics. I didn’t know that at first. I knew that we had done work I was proud of and that our partner and our client were happy with it. But it’s kind of the deal with consulting, you have to just let go and move on when the contract is up. But, a few months later, I got an email from Brad.

He didn’t share numbers, but he did share some of the deluge of emails he had gotten from people who were thrilled with the portal, before the training was even done. In the first week, in the first day, it was helping people who had been there for years find new information. He also reported being tackled with hugs in the hallway by grateful colleagues. At an insurance company. Over a new SharePoint intranet.

Adoption starts long before the solution gets rolled out. For us, it started with every user interview we did, where people felt heard, and continued with every colleague they told about this weird person in Seattle they had talked to on the phone, and everybody the project sponsor had been able to give a really good explanation to when asked a question. Whether or not a solution will really be embraced is often decided before you even start designing the training. Users don’t hate change, they hate feeling disregarded and like an expensive new solution doesn’t make their day any better. They don’t have to hate change, and they don’t have to hate us, either.

Thank you.