4

Background: we have recently made a significant change to the UI of our software. All previous versions used a MDI interface (windows floating around inside a parent window.) The new version uses a docked interface (windows snap next to each other, fill all available space, and can be tabbed on top of each other, and can be dragged out to another screen.) We thought - and still think - this is a great improvement. However, feedback from our alpha testers is wildly varying. Some love it, some say they find it hard to use and want to use the old system. Many of our users have been using the software for well over a decade and are very used to its old UI behaviour.

Generic situation: I'm sure other software houses have encountered similar problems, ie I think this is a widely applicable problem we will probably all encounter at some point: you make a change (especially a significant change) that you think will be greatly beneficial for the users of your software, and you don't receive universal acclaim.

  • How can you be certain that your change really is better for the user, instead of just a change you happen to like?

  • In my experience, change is usually liked more when it's voluntary or sought out, not forced. How do you enthuse your users so that it is voluntary? Should you even try? How do you handle this situation?

I have tagged this question 'delphi' because there is an interesting specific parallel: a decade or so ago the Delphi & C++Builder IDE (which we use!) changed from floating windows to a docked UI - exactly the same as us. A small, very vocal group of people complained loudly and some still do to this day. As far as I know, the majority think it was a great change. If there happen to be any Borland / Embarcadero staff reading who feel like chiming in with a historical tale, I'd love to hear your input!

|improve this question
  • 1
    If the alpha testers can come up with valid complaints, listen. If it's just "I like the old better" it's probably not a real issue. Think of all the dozens of Facebook groups that have protested new FB features, and then a month later everyone loves them. Nobody still complains about the very existence of the news feed, but it caused a riot when it was introduced. – Tesserex Mar 24 '11 at 2:56
  • 2
    Delphi supports both docked and undocked interfaces, so maybe thats your solution. – GrandmasterB Mar 24 '11 at 4:29
5

usability testing

before you make the change

You may have just spent a great deal of effort fixing a problem that did not exist!

|improve this answer
  • Good point! Luckily, we prototyped before implementation and it met with approval. I've also seen lots of users use our software 'in the field'. I'm pretty confident the way it was was not optimal. – David Mar 24 '11 at 4:19
  • 2
    @David so...you did usability testing with the old MDI interface, which identified some critical usability problems, and you determined that the solution to these problems was to change to a docked interface. Then you did usability testing with the docked interface and verified that the usability problems were indeed gone, and no significant new ones were created. Right? – Steven A. Lowe Mar 24 '11 at 13:57
  • Well, we are now testing with external users. In-house, our testing makes it seem better. Externally, it's mixed. Of course, some new usability problems were created - they always will be... IMo they're acceptable so long as they are resolved or are less bad than the original problems, ie net improvement. Ideally the new solution would be perfect. – David Mar 28 '11 at 1:13
  • 1
    @Stephen: I was trying to keep this question fairly generic so I won't add this to my question, but off the top of my head: window switching is hard (and they overlap so without manual arrangement data is obscured); the overlap requires manual alignment (Arrange All etc behave oddly - as a programmer I know it's based on the z-order, but as a user it's not clear); cannot be spread across multiple monitors; managing several windows at once (eg, different views of the same data) simply can't be done. A docked and tabbed interface solves all those. – David Mar 29 '11 at 1:15
  • 2
    @David: excellent info, thank you. A video demo/tutorial showing how it solves the old problems might calm the waters and reassure the users – Steven A. Lowe Mar 29 '11 at 14:36
4

Testing

In web development, A/B Testing is by far the best way to answer those questions.

To your specific example, have you tried giving it to new users and, better still, then given them the old product for comparison? It's absolutely true that a change to the UI can cause hellish problems in the short-term for experienced users of the old product.

But if it's better for someone who hasn't used the product before then it will almost certainly become better for the old users too, given time. However, sometimes what seems like a great idea to developers isn't great to the average person.

|improve this answer
  • I haven't heard of "A/B testing" as a phrase before; thanks for a link. We are in fact running a testing day with new users tomorrow - it will be interesting to see their feedback! Re better for old users over time: this is what we hope. How do they know that, though, or how do we get them to be happy or satisfied with the change? We like having happy customers :) – David Mar 24 '11 at 0:40
  • How hard would it be to give them the choice? Let's face it, a good number of WinXP Early Adopters switched back to 2K mode for a while – pdr Mar 24 '11 at 0:47
  • @pdr: sure, although it has to be worth the coding/QA/Doc time. But if we think it's worth leaving the old one in, why do we think it's worth having the new one? How or why should we be confident / not confident? And if we are confident, how should we present it to users? – David Mar 24 '11 at 0:57
  • 1
    Confidence: Testing again. Presentation: Gently. Understand their pain. Explain to them why you're sure it's better for them. And if they don't agree, but you're absolutely sure, go with it and I'll bet they're not complaining in three months. If they are, you've probably made a mistake. – pdr Mar 24 '11 at 1:05
  • I'm not certain Binary comparative techniques will be useful in this case. This technique can be useful to test small incremental change but in this case it would not provide much more than what he already know... some like it, some don't. Usability testing here would be MUCH more appropriate – Newtopian Mar 24 '11 at 3:00
3

Change is scary

Keep this in mind when you show long time users that you are changing everything about the way you interact with the application. While I personally think that your proposed change will be friendlier to new users, the long time users depend on the way things are. It took them a long time to become proficient, and they've all come up with little systems to make using the application more useful to them.

When you change everything "for the user's good" those users now have to relearn everything they already knew. It's a real disincentive. Think about your gut reaction when you saw Microsoft Office 2007 (or 2010) for the first time. "Where is everything?"

Change is an interruption, then it's done

People will adapt, however you have the user interface organized. To that end, consider the following questions:

  • How long does it take to adjust to the new way of doing things? For example, did you completely rearrange the menu structure while changing the way windows are organized? That can be a catastrophic no-no. Limit yourself to only one major UI change at a time.
  • Do new users learn the interface faster with the change or without it? You need to demonstrate some tangible benefit to the users. Use an A/B test with new users to focus your results. If you can reduce training costs with the UI change, you'll start to win over the pointy haired bosses.
  • Can existing users still do their job? The more a user has to do something, the quicker they will adapt. The problem is that if the change is too different and the user can't find the critical functions they need to do their job, you've failed them.

Can change be good?

Absolutely, yes. The question you have to answer is why is this change good? Are you saving the user steps? Are you reducing the amount of time twiddling with the screen and not doing work?

The next alpha test you do, apply the following:

  • Have the users perform a set of tasks on the old interface. Use screen capture to get a better idea of just how the user has found to make the app useful to them. Also, time them.
  • Have the users perform the same set of tasks on the new interface. Time them, and use screen capture to get a better idea of just where they are stumbling.
  • Once you've observed what they are doing, train them to bring their knowledge of the UI up to where yours is.
  • Now, tell them you are doing a speed drill. Have them do the same set of tasks as before on the new interface, but as quickly as they can. Give them some sort of incentive. The incentive doesn't have to be anything grand. It can be something as simple as cookies for the winner.
  • After all this, now ask them about their opinions.

What you are trying to do is educate the users how the change is really and truly better.

|improve this answer
  • Btw, "Limit yourself to only one major UI change at a time" is good advice, I think. This is the only major UI change in this version: the main menu is the same, shortcut menus are the same, menu items are in the same positions (for muscle memory), shortcuts are the same, etc. – David Mar 24 '11 at 1:32
1

Thou Shalt Not Surprise Users

A lot of users got used to your software and gained productivity. A major change of UI will be disaster to those who can already blind-type or blind-click inside your software. To them, how you layout the windows is irrelevant to their daily work. All they want is getting work done (faster). So if you slow them down, they will hate you.

Some like new stuff

Geek, developers and casual users usually like new stuff. Exchanging a mouse for a trackpad is fun to them. So this type of user welcome new interface and new themes.

Change or not

It really depends whether you want to sacrifice a group of your users for another.

Solution ?

Option. Allow your users to have an option. The option to use the new wonderfully dock-interface, or old efficient MDI interface.

|improve this answer
  • Thanks ohho. Having an option is something we've considered. To me, this has drawbacks: it's easy to add an option instead of making a choice, and then eventually your software has a proliferation of options. That leads to more combinations: more bugs. It's also more code to maintain, or to re-implement. Is it really the best solution? I guess I'm thinking, 'If you're so uncertain about feature X you go through all this to let the user use feature X-1, why have it?' – David Mar 24 '11 at 1:42
  • 1
    Many usability experts also believe that options are at best a cop out for actually making a decision. Not all change will be initially popular, but that doesn't mean it wasn't good. – Berin Loritsch Mar 24 '11 at 1:57
  • @David M: you may consider maintain only 2 versions, the latest version, plus a previous version. New features are only added to the new version. The old version receives bug fixes. Eventually, more users will migrate for the features (so you get revenue). And you still take care of the existing users. – ohho Mar 24 '11 at 3:19
1

There's not necessarily going to be a universally accepted approval of the change. Some people might find it better, and others will hate it. You just have to live with the fact that you're going to annoy some users and perhaps chase some customers away. Its about using your judgement - deciding what will help the most people, while limiting the annoyance to others, and most importantly, improving your overall sales.

Also dont just assume those users complaining about the change dont have legitimate reasons for doing so. Particularly if you made the change 'just because', which you see a lot of in this industry. If people are complaining about your switching from MDI to a docked interface, it may be because they cant as easily access the information they want to. Make sure you sit down with them and actually watch how they use the software. Developers and users use software differently. And users may have different hardware. That docked interface may look wonderful on your dual 24 inch 1080p wide-screen LCD monitors, but may be painful on a 17 inch 4:3 monitor, for example. Or the previous arrangement allowed them to minimize mouse movements, but with the new system they're fast developing carpal tunnel syndrome. Or before two items they need could be aligned right next to each other to be seen at a glance, whereas now it requires a head movement.

|improve this answer
1

User acceptance is the key. If the users don't like the change, you should not go for it. They are the ones who decide, not you. Just think about how many users the Microsoft Office engineers pissed when they decided to make major changes to the menus, layouts, etc. Did they think that the change was for good? Certainly. Did they test them on enough or the right users? It seems that not.

|improve this answer
0

What's the point? Is your goal to make the application more appealing to new users? Sometimes you have to move in that direction to grow your product and risk losing existing users. The usability may not improve, but it may "look" newer which gives the impression the product has the latest and greatest. You may have an older user base, so don't assume they have the latest and greatest hardware or operating system. I notice a lot of corporate laptops (stickers) on the train that are still on Windows XP.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.