This topic comes up a lot in conversations with our clients and other designers: users don’t like it when you change their software. What do we do about it?
The very talented Jared Spool likes to tell a story about how much users hate change. He asks us to begin by imagining our kitchen and our morning routine. We make coffee, cook breakfast for the kids, make our own breakfast, empty the dishwasher, clean up – it’s usually a busy time for us. But we know where everything is in the kitchen: and we work quickly. Next he asks us to imagine that one night while we’re asleep the usability fairies come into our home and fix our kitchen’s design. Everything is in a better place, now – much more ical, better traffic flow. Then you wake the next morning and come down and try to do your morning routine. Chaos and frustration ensue.
It’s a great example and it always gets a few laughs. Jared goes on to talk about the importance of designing the process of change – making sure that change isn’t something that just happens.
But what does it mean to design the process of change? What does “good change” look like? How do you roll out changes in a design without upsetting users.
Believe it or not, I’ve actually reorganized someone’s kitchen. I was visiting my friend Nannette, who is a great cook and had a large kitchen, but I noticed while watching her cook that she had to travel all over the kitchen to get the things she needed. I also noticed that some cabinets were empty and some drawers overstuffed. The whole system looked kind of haphazard to me. We talked about it for a while, and then I asked her if she’d let me fix her kitchen’s organization.
She agreed and we spent some time talking about what was and was not working for her. I added this discussion to my own observations and came up with my plan. While she was out the next day, I changed everything around. I fixed the kitchen’s design. The plastic storage containers were now near the place where they processed leftovers. The coffee makings were near the coffee maker. The things you need at the stove were now all near the stove. When she came home, I showed her everything I had done and walked her through all the changes and explained why I had made them. I watched her cook for the next few days, asked her questions, and tweaked the design, until we were both happy with it. Nannette’s reaction? She was thrilled. I did this in 2004 and she still tells me how much she loves it. (In case you’re thinking she’s too nice to tell me if she didn’t like it, we have the kind of friendship where it’s ok to say “I don’t like it”).
I had made massive change to Nannette’s kitchen – a total reorganization. Her morning routine was completely different the next day. But she loved it. What was the difference between Jared’s kitchen fairy story and what I did for Nannette?
- Nannette agreed that her kitchen needed help – she knew it was disorganized and she didn’t like it, and wanted it fixed.
- I asked her permission to make the changes – she knew it was coming and that there would be a period of adjustment, but she was ready for it (in particular, she made sure she knew where all the coffee stuff was before she went to bed that night).
- The changes I made really did make the kitchen better. I didn’t just change stuff for the sake of change or because I thought it would be cooler- the kitchen was improved. I knew this because I had interviewed Nannette and observed her using the kitchen, so I knew what the problems were and how to fix them.
- I walked her through the changes, showed them to her, and explained them.
- I stayed and watched my changes in use and answered her questions.
- I made some tweaks to her kitchen’s design based on my additional observations.
All of these ideas can be translated into how we manage change in software design.
Get the user’s buy-in
The more your users are ready for change, the better the experience will be. Let them know what you’re planning. You can tell users that change is coming through announcements: on your web site, emails, blog entries. Talk to them about what you will be doing and why. Talk about the problems you’ll be solving, and show them some early mockups of the work. Take look at Balsamiq’s blog – they have an ongoing discussion about features that will soon be added to the product. Users who follow the blog are never surprised by upcoming changes. They even share mockups of designs they’re considering and ask for user feedback.
In addition to your usability studies and field studies, get your users involved in the conversation about what needs to be changed. We live in a social media world – if you’re not listening to your users, you are missing out on some great information. Balsamiq also has lively “Ideas” section in their Support pages. Users are encouraged to submit their requests and ideas. Unlike many companies where such submissions remain in “support” or just die out, these suggestions go directly into product development. Some examples:
- A request for a change to how resize works for text areas and post-its – the idea is under consideration for inclusion in a future release
- A request for a feature that’s already there
- A list of all the ideas that were submitted that have been implemented (17 pages of them, folks!)
Your users can be extremely articulate about their needs, and they love a company that actually listens to them and responds.
One thing to keep in mind, though, is that your users are not designers (well, many of Balsamiq’s users are designers, but they’re in an unusual position). Your users can identify their problems, the issues they’re having, the things that take too long, or the things they’d like to do with the software, but that doesn’t mean that they can give you a design. Your users will focus narrowly on their problems – your job is to look at the whole product and all of its features. You still need to do the work of finding the right set of features and the right design to solve the problems they identify.
Get the user’s permission
It used to be that users would go out and buy a software upgrade and install it when they were ready. In many places they still do: Microsoft Office or Apple’s OSX, for example. In those cases, the onus is on the company to motivate the users to buy and install an upgrade. Heck, even when upgrades are free (as with iOS), the company has to convince the user that its a good idea. While some users never choose to upgrade, most eventually do, but at the time and place of their choosing. Below, Apple starts selling new OS X upgrade months ahead of launch with videos, screen shots, and big glossy pages.
This method – allowing the users to decide when to update – has been around for decades. Almost all desktop applications still follow this model … but few web applications do. With web based applications we see a very different dynamic – the software updates on its own, without the user’s permission. The user sits down one day at their desk and Boom! The usability fairies have attacked (I see a t-shirt design in someone’s future) and the application is upgraded.
If the users must upgrade then there’s no choice. How do you get the user’s permission in these cases? Ultimately, I think it’s about control. Users want to feel that they’re in control of change. In particular, they want to decide when to upgrade.
Giving Users Control #1: Tell your users an upgrade is coming. Create materials to show off your design, explain the problems you’re fixing, and showcase new features. Let them know that there’s a deadline coming and that on the deadline everyone will upgrade. They should know they have to start getting used to the idea that change is coming.
Giving Users Control #2: Let users who want to get on board early go ahead and test drive or preview the upgrade. Make sure that a test drive is not the same thing as agreeing to upgrade – they should be able to explore new features without committing to the upgrade.
Giving Users Control #3: Allow the users to upgrade ahead of the deadline – that way your users can pick the moment when they’re ready to deal with the change.
When Facebook rolled out the new Timeline feature, they put together a tour that showed users what the feature was like and answered key questions that users might have. Then, they allowed users to go ahead and migrate to Timeline early, if they wanted to. The result was that some early adopters jumped on board, and then (because it is a social network, after all) other users started saying: hey, how did you get that new Timeline thingy? It was cool to upgrade. And pretty soon, users were jumping on board the new design.
You’ve had to buy upgrades for your desktop software, right? And let me guess: you usually wait until you have a day that isn’t so high pressure to actually do the install. Heck, you might set aside and hour or two to make sure everything is working just right. This is part of the kitchen fairy story: what sucks about the kitchen redesign is that you have to deal with massive change in a high pressure situation: breakfast for the family. When I redesigned Nannette’s kitchen, she knew it was coming and she didn’t plan to cook a big complicated dinner that night. I made the changes when she was ready and gave her time to get used to the new design. Your users deserve the same courtesy.
Make sure it’s better
Maybe this seems obvious, but I want to be really clear: don’t subject your users to massive design changes that don’t actually make things better. Do your research: your observations, your field studies, your usability studies, your mockups and prototypes, more usability studies. You have to actually make the pain of adjustment worth it to your users. Will all your users agree that every new feature was good and useful? No, of course not. But Nannette would not have been very pleased with me if I had just randomly rearranged her kitchen and she certainly wouldn’t have asked me to do it again. If you throw bad designs at your users, they will come to resent you and they will not trust you.
One thing I’ve learned over the years is that users always have pet peeves about a product. If you talk to enough users you will learn what these are. They’re usually little things, but they drive the users crazy (Why do I have to click this button to load the information? Why can’t it just do it for me?) I set a mark for my clients: go after at least ten pet peeves in every release. Ask your users to tell you about their pet peeves – then fix them. I can’t tell you how happy this makes users – delirious. I’ve talked with users who ignore all the new features that we added to the product, only to rave about the two or three pet peeves that we fixed.
The corollary to “make sure it’s better” is don’t add new problems. How do you avoid this? Prototyping and user testing. Make sure you put your new designs down in front of users early and often. As you roll out your new design and early adopters start using it, be sure you’re gathering their feedback – this is your last chance to spot problems before everyone is on board. And don’t make changes just for the sake of change – make them matter.
Here’s an example: we’ve worked with a few clients over the years who have data entry intense applications: users who will sit at the keyboard for hours and fill in forms. The users are usually evaluated on how many forms they can complete per hour, so speed and accuracy are important to them. They often aren’t even looking at the screen as they type – just pressing the tab key to move between fields and enter information. One of our clients took an existing form and rearranged the elements on the form. They did this because the new arrangement just “seemed better”, not because they were solving any particular design problem. And indeed, the new layout was neater looking. But for the users it was a big problem: they had to learn a whole new tab order for the form. It was incredibly painful and over the course of a few days and weeks the users did learn the new tab order, but for them this change created huge new problems.
Tell the user about the changes
When Nannette came back from her day out, I gave her a complete tour of her new kitchen design. I walked her through it, explained the problems I’d solved for her, and share my thinking. She would have eventually figured everything out on her own, of course, but my tour changed the whole nature of the experience. Instead of just opening cabinets and seeing what was new, Nannette got to hear me talk about what I changed, why I changed it, and what problems I was solving. I was able to put the changes in context. As a result, she was able to learn about the changes more quickly and remember them more easily.
A common tool for this is the “help bubble”. In the Google Docs example, above, the user can “Learn more” about the change by clicking on the link. In the eBay example, below, they have a 6-step tour. The user clicks “Next” to visit each “help bubble” and see the changes. In the final step they highlight the “Tell us what you think” link to get feedback.
These “help bubbles” can be used in a mobile or tablet environment, too.
The new version of iPhoto for the iPad comes with help bubbles – they show several at once and offer a “Get more help” button, too.
You can also create a set of materials that cover all of the changes for your users. These can include images, videos and supporting text. WordPress, below, created a “Welcome” page for users who have upgraded.
Sometimes your users are gone for a long time before they return to your application. You may have upgraded without their knowledge or consent – how do you tell them about it? Wufoo has a “Since You’ve Been Gone” page that explains all the recent “updates” and links to their Blog. The folks at Balsamiq have Release notes that do the same job.
Keep a watchful eye
You should be able to answer the question: how is the new release going for our users? You should know what your users are saying. Did you introduce some horrid little problem that’s bothering them? Fix it. Did you miss something, but hope to get to it in the next release? Tell them about it. Don’t just ship it and turn away – change is a process and you need to be there to guide it. When I reworked Nannette’s kitchen, I tweaked my design over the next few days as I watched her use it.
Maybe you need a completely new product
The folks at 37signals wanted to change their flagship product, Basecamp. They wanted to change it a lot – not just the design, but also the underlying code. So they decided to release a completely new product with lots of new features. And they continue to support the old version (Basecamp Classic), as well. Jason Fried writes:
And that’s where we found ourselves with Basecamp—a successful product that was tough to change in major ways. Of course, it has evolved; over the years, we’ve made thousands of incremental improvements to the software. But now we have ideas that are more revolutionary than incremental. We think these ideas will dramatically enhance Basecamp’s speed, power, and flexibility.
37Signals launched the new Basecamp in March, 2012. At the end of that month, the new design was being embraced more quickly than before and lots of new customers were coming on board. Jason Fried writes:
Usage is fantastic. On a per account basis, new Basecamp accounts are creating twice as many projects and todo items as on Basecamp Classic, as well as more attachments, messages, comments, calendar events, and more.
The “whole new product” route is a big step – there’s a lot of thought that has to go into how you market and manage two products. I’ll point out that making a new product still means that they have to manage change – they’ve launched a new web site to market the new Basecamp and still have a tour of the product with a free 45-day trial.
Design the process of change
I want to close and leave you with the thought that change isn’t just something you “let happen”. Your work doesn’t end when all the design changes have been made and new features have been added. You also have to think about how you will communicate all of this to your users so that the experience of upgrading can be as pleasant as possible. When you do this right, you build a sense of trust with your users. When you do it really well, your users will rave about your product.
… oh and watch out for those usability fairies. I think I saw one in your kitchen yesterday.