I'm starting a new project in the new year. I'm really excited about it. I can't talk about any specifics but it is a long term project in which me and my colleagues are working to integrate two large entreprise applications with disparate user experiences.From my previous life as a programmer, I know that integrating two disparate applications is really difficult. However, I have a good idea of how I'd go about it. Refactoring here is the tool of choice. Refactoring is a challenging and rewarding practice that, when done right, improves the software significantly and safely. So naturally, I tried to find the equivalent on the user experience side.
Asking Google gave me a couple of articles. Most of which were making the case for it but none discussed what it would really look like. The more I thought about it, the more I wondered if you can refactor the user experience. By definition, code refactoring is "a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior".
Code refactoring is a technique that works because it is based on a strict set of rules. For example:
- Test profusely
- Think globally, act locally
- You can't change external behaviour
- Don't add new functionality while refactoring
- Don't repeat yourself (don't copy-paste, always cut-paste)
- and much more...
What would refactoring the user experience look like? What would the rules be?
Off the top of my head, here's a first kick at possible rules:
- Test profusely (before and after refactoring)
- Set a big picture goal. Always move towards that goal with each change
- You can't change the user's mental model (unless testing tells you it was wrong before)
- Adding new features is not refactoring.
- Jump at the opportunity to remove/hide/displace an unused feature when possible
So maybe it is possible to refactor a user experience. If it is, maybe there is a set of reusable rules that can be written down in a recipe book. I'll keep my eyes opened for things that I can see and my ears opened for any suggestions you might have.
3 comments:
"You can't change the user's mental model (unless testing tells you it was wrong before)"
Even if the mental model is wrong, I don't think refactoring is a good time to change it.
In programming, it's really dangerous to start fixing broken things while refactoring simply because as soon as you fix one TODO, you will start to see everything as an issue.
Especially since you're merging two large designs, I'm sure you will find a ton of problems. If you fix them as they come up, you'll be mixing refactoring with bug fixing, and the process could drag on forever. (Though I'm sure you'd never let it get to that point.)
I'm interested to see how this turns out. Remember to blog about it afterwards, I feel like there's going to be a great case study in this :)
Ah! good catch. You can't fix the user's mental model. It is the user's mental model.
Maybe the user has developed workarounds to map their mental model around the legacy system's data. Maybe that has become their new mental model.
I am having a hard time with this one. Let me try to clarify my thoughts.
When merging the 2 systems, the resulting system can only have one consistent model for its data/tasks. Hopefully, that model is a match for the user's mental model.
• In my past as an SAP employee I have worked on projects that integrated the SAP Bussiness Data into Outlook – this project was called Duet. Working on this helped me learn the following:
1. Business objects are the same due to the same mental model but the UX may be very different. The UX selected should be consistent with the experience of the environment you are integrating into (if its mobile its mobile experience, if its web its web experience) trying to combine 2 environments into one is confusing for the users due to loss of consistency!
2. In the case of integrating into a well-known environment a mapping should be done between existing objects embodiment (In the case of outlook for example a mail and a task) and new objects to be added (a vacation request may appear as a task but a push business report is more suitable to be an mail).
3. The environment you are working from changes the tasks you may want to do:
a. For example it will be hard for me to write a long reply on the IPhone and so one should expect writing mostly short responses from an Iphone. Therefor if you send a vacation request the user should be able respond with one click and obligating him to write a long sentence is bad UX.
b. Another example is if I am using mobile device with a sales application, localization services may bring me a lot of value once I am on the road (Where is a close by costumer?) . This requirment is not that relevant in a desktop app. This means that you should think about the user stories from the beginning and not try to give the exact experience as in the original one.
4. I found that If you are integrating business data into tools that the user uses a lot (like outlook – in the case of Duet) you want to be as less disruptive as possible to the existing flows:
a. This means that adding 3 menu items to a 7 option menu should be avoided for example.
b. One of the ways to be disruptive is to be inconsistent with the environment!
Post a Comment