TRANSCRIPT: UX Week 2010 – Paula Wellings & Cameron Gray
Laura Says, “People Don’t Want Features”: Turning a Developer-driven Organization into a UX Company
Cameron Gray: Hi, I’m Cameron Gray, and I’m here to talk to you today about the work that Paula and I did to transform Mindflash from a developer-driven organization to a UX-focused organization. And that’s Laura, but we’ll get to her. She’s actually in the audience too.
So the first thing that you need to know about me is I’m an engineer. I run product and engineering, but I come from an engineering background, and until not too long ago, I was writing code on a fairly regular basis.
This means I am not a designer. I’m not a user experience expert. I didn’t go to design school.
I’m still a little surprised that Peter invited me to speak here today. But I put on my best jeans and a sport coat and did my slides in Keynote, so I figured you’ll let me stay.
As an engineer, I’m a system thinker, something Paula accuses me of on a regular basis. And I thought that Michael Lopp, in his latest book, really captured what it means to be a system thinker. And as a system thinker, we’re always looking for the rules, because when we have the rules, we know that we can win. This means that system thinkers build products from a feature-based approach. We particularly like competitive feature analysis. It’s great, right? Because I’ve got the rules, and once I know the rules, I just need to check all the boxes and I win.
In 2008, at Mindflash we took this approach to build a new version of our training platform, which we so elegantly named V2. And it looked a little bit like this. As you can imagine, this didn’t really resonate with the marketplace like we hoped it would. It had a million features and functions, it had everything you could turn on and off, and it was really, really difficult to use. And it was a really tough moment for us, and it wasn’t very long after we launched this product that the management team at Mindflash came to some really tough conclusions and realized that it was time to start over. And that was when we met Paula and Adaptive Path.
Paula Wellings: Thank you. Hi. I’m Paula Wellings from Adaptive Path. I’m a designer. Oops, and I just made the slides go away. I’m a designer, and I am very interested in how people do things. I spend a lot of time listening and watching people, and starting to figure out what exactly is going on there.
Something else to know about me is I’m an ex-academic, which means I don’t read journals anymore; now I read anthologies. Along those lines, I’m especially interested in situative cognition and essentially how do people in the real world learn how to do things every day in their life.
The other thing to know about me is I’m a designer and I like puzzles. I am especially interested in logic puzzles, but also in people puzzles.
And that leads me really to be especially interested in something I would term the inflection point: when something is heading in one direction, and for some reason it turns and starts heading in another direction.
I think what happened when we first joined with Mindflash is we appeared at a very specific moment in time, where they were essentially having a sensitive period for change. And what that meant was, there was four key things that were happening. Mindflash had just had a fantastic failure, which means that the status quo wasn’t working and they were actually looking for something new, a new approach.
The second thing was they were very clear that they had a key driver that essentially meant that, in order for their business to be successful as a software-as-a-service product, they needed to stop answering the phone; they needed to stop guiding every single person through their product. And this was a key business driver that led to all the decisions we made from that point forward.
The other thing is they had a resilient attitude. Essentially what had happened is they had just built something, spent an entire year working on it, and at the end of that year they were willing and open to starting over and killing all their favorite features if need be.
And I think the fourth thing was they had a good core technology. There were things useful and important in their product, if people could just figure out how to use them.
And so we sort of noticed that we were in this important moment. So what we did at Adaptive Path is we put together the team, and the team was sorta like this, but actually like this.
And when we arrived at Mindflash, we drove in something like this. But nonetheless, we had a team, and we had a plan. And the plan you’ll see here is not really that unusual. Grok the situation, understand the business, understand the customers, and actually very importantly, understand the existing product. You could say, “Well, it tanked. Why’d you spend any time on it?” The reason we spent time on Mindflash’s existing product was, it was a tangible place we could begin to engage the organization in a conversation about what a user experience is by, in some ways, leveraging the existing product to define what a user experience is not.
And so what I would say is, this plan overall is not especially unique. Especially if you’re a designer or a consultant, you’d be like, “Yeah, we understand it. We make a vision; we make a thing.” This was not unique, but I think what’s important to know is that this plan didn’t just change the product. Part of implementing this plan at this particular moment gave us an opportunity to actually change an entire organization.
And so what Cameron and I are going to be doing today is we’re gonna be sorta sharing, in retrospect, what the five critical moves were that we made to essentially turn a developer-driven organization into a user experience company.
Cameron Gray: So our first critical move is there are no quick wins. When our product didn’t take off the way we thought it would, we initially had this mad scramble, like “Oh, this is no problem. We can fix this.” So we thought, “Ah, wizards in contextual help, right? That’ll fix everything.” This is a great example here where we’ve got contextual help, but because you can turn so many things on and off in the product, you could get contextual help where it points to a button that’s not actually there. Then we thought, “Oh, visual design, right? We’ll just make it look pretty, and it’ll be usable.”
These are the sort of immediate quick-wins approaches, and they were not successful for us. And that meant that we had a long road to go. First thing we had to do was we had to change our organization. We were moving towards a more UX focus. That means people’s jobs change. People who were doing one thing every day, you’re taking phone calls, now you’re a product manager. That’s tough.
This also means that we had to learn a whole new technology, because to make a front end for our application that sat on top of our core technology that was really useful and usable and desirable, we needed to do something different.
And finally, we still had this Version 2 product out there that had customers on it that we had this bad relationship with, and we had to tell them honestly that we were taking this thing to end-of-life, and their time was running out. And actually, they really appreciated us being so honest with ‘em.
And it also took time. It took a lot of time. From the first day that we engaged with Adaptive Path through our workshop, through actually building the product and seeing it into private beta, was a year. We think it was worth it, and I wanna show you just a quick video of what we built.
Female: The Mindflash training management system provides small to medium businesses with an easy and effective way to deliver in-house training online. We save trainers significant time and money by giving them the ability to create multimedia, Web-hosted courses from existing training material in minutes. And with our quizzing tools, it’s simple to make sure your trainees are getting it. We automate trainee invitation and track progress in our reporting tool, giving in-house trainers the confidence that they can quickly and successfully train employees in job-critical information. Mindflash makes it easy to get your training online. Give it a try by visiting us at Mindflash.com.
Paula Wellings: When we first arrived at Mindflash, I think something to keep in mind is we showed up to the organization that was about 20 people at the time. And everybody there had just spent the entire last year staying up late at night, working hard on the software, making every release come out. People were working hard on marketing their product, on attempting to sell their product, on supporting their product. And we walked into there knowing that it hadn’t been successful and knowing that everybody there had just done blood, sweat, and tears.
The other thing we knew from our stakeholder interviews is we knew that, even in a 20-person company, people in customer service didn’t talk to developers. They did interpersonally; they made chit-chat. But actually talking about the product and where the product was heading was never a conversation that took place between developers and customer service.
And so when we came in, one of the strategies that we really brought to the table was everybody plays. And what you might think is, “everybody plays” sounds like a way to make, like, too many cooks in the kitchen, and it’s gonna be yucky and a disaster ’cause it’s mediocre; this person wants this, this person wants this.
And so I think it’s really important to note that we said “everybody plays,” and it was really important to us to look at how we might leverage the knowledge of the organization. Some folks at Mindflash had been there for six or seven years, had understood and followed their products through a number of different iterations, some successful and obviously some less successful.
And so we sorta had these high, kind of blue-sky ideas of how we could create a sense of shared destiny in this product. And that sounds really great, but I think it’s really important to note that when we went in and said, “We’re gonna do this thing all together,” that we did things like this. We made a list of exactly who was going to sit with who at every single sort of brainstorming or group session. And if you think planning a wedding is difficult –
– this is even harder. And you’ll note, we do, just like a wedding, have the things of who should not be sitting together and who must sit together so they can have an important conversation.
So what we did all together is we listed all the known needs, and notice I say “list.” We are not brainstorming needs; we are looking at all the needs we know from our contextual research, from things that people know from having worked on previous products, from what people know in the organization from listening to their customers. Adaptive Path comes in, and we’ve maybe been spending a month or two understanding people’s customers, but it’s important to know that Mindflash had been spending time trying to distill and understand what their customers wanted for quite a long time.
And so we listed all the known needs, and we identified the ones that we really must meet. And one of the most important things about needs and really clarifying them is noting that needs are things like “I need to interact with my trainees”; “I need to know that people are paying attention and getting what I’m trying to teach them.” Needs are not “I need five different kinds of multiple-choice questions.” Needs are not “I need 14 levels of administrator support.” Needs are not “I need a magic course fixer.” And differentiating needs from solutions really starts to give people a place to understand the people that we’re designing for.
And then the next part was that, once we had needs, was giving everybody an opportunity to share every good solution. Sorta like “bring out your dead.” That means people sometimes wrestled in their drawers, in their cabinets, in “that idea that I had last year, and if we had only done my idea, then our product would’ve been so much more successful.” And every single person shared every single good idea. And we did that essentially so we can prioritize, and everybody together can prioritize.
And throughout this, we really kinda structured an experience where everyone’s work is important and everyone participated. And I think we all sort of learned, like, yeah, everyone’s important, and here we all are. But on the second day of the workshop, it was about 4:00 in the afternoon, and we were running a little late, and we were like, “Okay, now we’re making scenarios,” and everyone’s making a scenario. And someone approached us and basically said, “I’m really, really sorry, but I need to go home.” And we’re like, “Oh, okay.”
And what we very quickly realized, for those of us not in Santa Barbara, was the whole town was on fire. And people were still at our workshop, still trying to get stuff done. And I think what it really said to us is that there is something about being part of your future, no matter if you’re, like, the junior developer or the person who answers the phone, is people were invested in being part of their future, to the point where one guy was like, “My pregnant wife needs to be evacuated from the fire zone, so I’m just gonna go now.”
Something else that I think is worth really knowing is we had this great workshop, and everybody felt connected and part of the vision. But to go from that great one experience to something that continues and is embedded in the organization, people really need tools to think with.
And so we essentially created three what I would say are very important tools that lived in everybody’s everyday life. The first thing is we really differentiated and clarified the competitive landscape. And that meant that, historically, Mindflash had created a product that was great for universities, that spoke “university” really well. And what we were able to do with our research was essentially say that e-learning is not training. When people who are trainers go to work and try to teach people stuff, it’s because they like people; they wanna connect with people. They’re not great at making multiple-choice quizzes. And so really clarifying where are we and where aren’t we.
The second thing we did was we represented customers so that they are the focus of decision making. And I think it’s really important to know that – I think a lot of people make personas, but I think personas that people can actually bring into the decision process every day is really important.
Male: And we look at what a persona would be, which helps us direct our software to a specific market, which really gives us an advantage over, say, V2, which was the previous product, which had much less focus and ended up not getting much traction, I believe, because it was hard to define what you would do with it.
Paula Wellings: And the third thing that we did was we made principles that put customers first. And I think when Cameron spoke at the beginning, he spoke about being a systems thinker and how, like, if you can figure out the right rules, you can essentially win at the end. And to a certain extent, rules are really attractive, and so what we essentially did is we created a set of rules that have people consequences. So for example, one of our rules was that the system is the face of the trainer. And what that means, practically, for people in everyday life is that I might, as a trainer, launch a training course to 40 people, and if it crashes on the third click for everybody, you know who looks bad? Me as a trainer looks bad. I lose face. I don’t look professional.
And being able to communicate that to developers completely changes how developers understand their bugs, and bug regression becomes a completely different act which is about really kinda supporting and loving our customer.
Male: Design principles are kinda like the ten commandments of Mindflash. Basically, they’re good for keeping in mind basically guidelines for what we are trying to do.
Paula Wellings: And so we created these three principles essentially to empower people to focus by saying “no.” And what that meant was no longer could internal politics make something happen; no longer could someone’s pet project sorta become something that everyone suddenly works on. And the other thing was, all of a sudden just a love for technology and a love for features wasn’t enough to really drive how the product was made.
Male: For us, one of the big issues is simplicity, because we don’t necessarily talk to our customers or walk them through the process of trying our products or even their first experience. Making it so that it’s very easy to use and intuitive is critical to our sales process, so the very first time they come in, do they know what to do, and are there a million features that they have to turn off or on in order to get it to do what they want it to do? We really wanna stay away from that, so simplicity, I think, is – and ease of use is really our No. 1 thing.
Cameron Gray: So the fourth critical move is to encourage fishing. And by that we mean transform your entire organization to learn to be user experience designers in some capacity.
The first thing that we had to do was change our thinking, and more importantly – or specifically, get rid of our old vocabulary. We had all these legacy products that had ingrained all this language, and we weren’t speaking the language of our customers; we were trying to teach our customers a language we wanted them to speak instead of listening to them.
So one of our account managers had this great idea to create the “Laura Says” posters, featuring Laura, our product manager, telling us what our new language should be.
Female: They’re life lessons that you’re supposed to take to heart, where she tells us the truths about life and also our advanced terminology for things that we have to learn to say and what we have to unlearn to say from our legacy products, so that we have a common language. And it’s funny to see her in cartoon format.
Cameron Gray: This, of course, led us to put stickers all over the office with Laura saying all sorts of fun things and are still up there. And everyone’s personal favorite was, “Laura says, ‘Hanson rocks the hizzouse.’”
We also had to make usability and user testing a core part of everyday life at Mindflash, and we did that using something called pizzability.
Female: The best usability sessions ever. Free pizza. Pizzability is when the whole company would get together at lunchtime, bring in some pizzas, and we would watch usability sessions, either mashed-up, different sections of different people’s usability or just an entire session of one person and how they used the product, so it allowed the entire company to see how actual people were using our product and see where the hang-ups were and where the successes were.
Cameron Gray: Once you have a product in the wild, the really important skill to learn is you’ve gotta keep listening to your customers, just like you did when you did generative research like we did with Adaptive Path. And for us, that means we…
Male: I think probably one of the most important things is to understand that we’re a listening company and that we really care about spending time and investing and hearing what customers and users have to say, and that we respect the users. If the user fails, it’s not their failure; it’s our failure. And I think that that’s a really key thing.
Cameron Gray: For us, this means that we test everything with real users all the time. We test wireframes and new designs before we build them. We’re an agile team that operate on a sprint calendar, so we test every product iteration as we complete it. And once we have things out there, we just continue to test and test, with real users, and it’s really, really important for us to make sure we recruit users that meet our target market. So testing usability with your mom just isn’t as useful as you think it would be.
It also means that we had to provide a way for our customers to speak to us, because that’s the easiest way to listen, right? And we’re a SAAS, a pure SAAS, so people aren’t calling us on the phone. We have to have customer forums. We have to have places where customers can post ideas. And we have to have a combination of passive and active listening. So actively we’re seeing cases come in, but passively we’re using analytics and we’re using our own internal reporting systems to understand what’s the behavior that matches the communication that we’re getting from the customers.
Our fifth lesson – or our fifth critical move, which is really important. You still need pros on board. So as a system thinker, when you discover, like I did, user experience design as a concept, your initial reaction is, “Oh, no worries. I can understand everything there is to know about this. I’ll just start reading all these books, because somewhere in here I’ll find the rules of user experience design, and then I can win with it.”
Failing that, you’ll just hire the best consultants you can find, and you’ll keep them around forever. We signed statement of work upon statement of work upon statement of work with Adaptive Path, thinking, “Well, they’ll just keep staying around.”
And then, of course, we make user experience design part of our everyday culture with things like pizzability. Well, as an agile team who releases product iterations every four weeks, we find new challenges every four weeks. Every time we release something we learn something new, and every time it’s like, “Oh, gosh, we wish we could go back to Adaptive Path and say, ‘Wait a second, this is new and different, and the personas, the design principles don’t help us here. What do we do?’” And what we found was we needed to have pros on board.
So this is on of our Scrum teams, ’cause we’re an agile shop doing Scrum, and it’s got all the usual cast of characters that you would see in a Scrum team. We have representatives for product. Of course, we have representatives from engineering. We’ve got folks from QA. And what we realized was critically important for us to be successful was to add this guy in the back, and every Scrum team in every organization should have one of them.
Male: I think Adaptive Path has been kinda like the training wheels on a bike that we really wanted to ride but didn’t know how, and that bike is our software. Basically, in order to be on our own at this point, we kinda needed them to guide us and help us in the beginning, because we just didn’t really know how to make that kind of roadmap that they were able to create for us. And that was a hugely important thing in the development of our product.
Cameron Gray: And those are our five critical moves.
Peter Merholz: I’m wondering if you have any kind of – I know this is something that a lot of folks are thinking about – any just kind of top-of-mind thoughts around agile development, user experience, how they can work together, how in my experience UX tends to feel kind of run roughshod over by agile developers who are trying to launch something every week or two, and the user experience people are like, “Can we think about it first?” So what has worked just in terms of kind of integrating user experience processes that tend to work at kinda one cycle and agile processes that tend to work at other cycles?
Cameron Gray: I think that the really interesting thing about it was that people who do user experience design think of themselves as being involved in an iterative process. But engineers think, “Oh, well, all design’s waterfall.” It’s like, you know, you go do research, then you produce design, and then you give it to us and we build it.
And what we really needed to do was sort of overlap those iterative processes and sorta stagger them in a way. So I’m iterating on design, and I’m delivering increments of design to a development team, who can then deliver incremental product based on that, and you see incremental value. And as long as you’re committed to that and you realize that you can always change, you can always evolve, you’re not designing something that’s gonna be live in three years, then you take a lot of the risk away, and people are willing to maybe not finish everything perfectly but get it out there and see how it does.
Peter Merholz: All right, anybody? Any questions?
Audience Member: I was wondering, where did the proposal to bring in Adaptive Path actually pop up in the organization, and how did it go from “Okay, we need a UX person” to “Okay, we’re working with Adaptive Path”?
Cameron Gray: It was actually – I have to say, like I said before with the quick wins, we spent some time trying to solve our problems on our own, and that was when we really started looking around and studying what other organizations had done that would be successful. And we went through a really quick process, and we met with a lot of different design studios. And when we sat down with the folks at Adaptive Path, I think they just really resonated with us and said, “Hey, this is the right people to work with,” and presented us sort of a rough design strategy based on experience that they’d had with other products, and then presented Paula as somebody that seemed like a really good fit for our space. So it was really a really personal decision about who we felt were the right people to be part of our team.
Peter Merholz: And Paula, do you have anything from your side in terms of how the relationship started?
Paula Wellings: Well, I do think we started the relationship. I think to a certain extent you guys were like, “Can you fix what we got?” And we did start the relationship saying, “Okay, we’ll try and fix what you got.” And so we actually, in our proposal, included a round of quick wins that would fix what they got while we tried to figure out what to do next. And I think, as Cameron mentioned, most of those were interesting as conversation and relationship builders, but as far as impacting the existing product, I don’t think they really brought a lot of value aside from helping us better understand each other.
Peter Merholz: Thank you for your question. Thank you guys for your time.
Paula Wellings: Thank you.
[End of Audio]
Transcripts provided by Verbalink