Tip:
Highlight text to annotate it
X
bjbj 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. [Audience laughter]
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.
[Audience laughter] 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. [Audience laughter] 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. [Audience laughter] 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.
[Video plays] 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. [Video ends] 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 *** the software, making
every release come out. People were working *** 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
[Audience laughter] 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. [Video plays] 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. [Video ends] 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. [Video plays] 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. [Video ends] 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. [Video plays] 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. [Video ends] 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. [Video plays]
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. [Video ends] 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.'" [Audience laughter] 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.
[Video plays] 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. [Video ends] 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... [Video plays] 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. [Video ends] 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
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. Audience Member: 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. Audience Member: 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. Audience Member: Thank you for your question. Thank
you guys for your time. Paula Wellings: Thank you. [End of Audio] UX Week 2010 Paula Wellings
and Cameron Gray Laura Says People Don't Want Features Paula Wellings, Cameron Gray, Audience
Member Page PAGE of NUMPAGES www.verbalink.com Page PAGE of NUMPAGES hpOW hpOW gdeN hpOW
hpOW gdeN h6g< hpOW hpOW hq