When it comes to “good” and “bad” in User Experience Design, it’s all about making compromises. There are influences from marketing, management, development, design, sales, support, etc. In other words, almost every role or department within the development cycle has it’s own agenda on want they want to see in the final product. But for the moment I just want to use only three parties, which in most of the projects I have experienced had the most influence.
Shifting the influence pillars
The three pillars I am using are Business, Architecture and Design. The one with the most influence, it usually determined through politics (in other words, who’s got the biggest mouth). But ideally you want this to be clear before the project starts.
The amount of influence is often based by your organization. If you mainly have developers, then probably the application architecture will determine how your application will be used. When you have a large sales force, or you outsource a lot of your work, you mainly are trying to keep your customer happy by obeying to all their wishes. Thereby allowing the business (customer or analysts) to determine how the final user experience will be. And if your company is mainly a design company, your interface or graphical designers will be the ones calling the shots.
These things do conflict, and I can imagine that project managers have there hands full with it. But what has this got to do with User Experience.
Well, User Experience is the way how your users work with the very thing you’re creating. And most of the time you can see which party had the most influence in building the application. This doesn’t mean it’s a bad thing. You just need to be aware of this in how this results in the application experience of your end-users.
This is why I strongly recommend that from the very first moment of the project, someone is guarding the User Experience. Maybe you see this as an extra block in the pillar, but I like to see it more as someone who negotiates and glues the interests of the different parties. In the initial stage he will cooperate with requirements to determine the best user experience for the application. Next this will be tested with prototyping. And finally during the development cycle he is guarding the end-user so when it comes to compromising, the outcome must be their best interest. (more about integrating UX in your project, see my previous post)
This is the “Good” when it comes to User Experience. “Bad” is when you are not doing anything about UX at all. At the moment where one of the influence blocks takes the lead and determines how the Application becomes.
When your design is beautiful and full of “chrome”, but without functionality.
A João Sabino design. Perhaps beautiful, but do you see anyone carrying it around? Get yours here.
When your developers are building the interface, and yeah, functional it’ll do, and programmatically it’ll probably be beautiful. But will your users be able to work with it?
Who on earth would have typed this address manually as the message suggests?
And how would you answer this “question”? Thnkx stan.
And if the business gets all that they want. Then at the moment you release your product it’ll probably be “not exactly what they had in mind”. Or worse, it is exactly what they wanted, only the end-users aren’t able to work with it, because of the complexity, inconsistency, or perhaps the environment required a somewhat different type of approach.
Reset inscription underneath button. But reset what? Reset missing toilet paper? Thnkx greg.
Costs and benefits for UX decisions
When you are talking about making compromises, it’s making decisions between costs and benefits. For example, create a seamless integration between different application clients, so if the data changes in one of them, the other one changes with it (with some kind of notification when needed). Another example is working asynchronously, so the interface is always accessible and able to display progress. The costs of such implementations is extra development time, a different application architecture and probably configuration changes on the application server. But when talking about the benefits, in the first example it’ll result in more reliable data because of less version conflicts, faster communication between collaborating users, which in turn increase productivity. And the second example has the benefits of a faster working application, better feedback, and probably less frustrations. For both examples this will result in a much better user experience that overall increases the happiness of your users.
Third example is of a user that works in a very busy environment, where it is common he will be disturbed regularly. Then it would be very nice that the application he is using, enables him to keep track at his current progress, so when he is distracted, and continue his work, he can instantly see where he’d stopped, so he can pick it up from there. Costs and benefits are much the same as with the first examples. More work but also a more productive user.
Most of the costs are directly related to budget (more work takes more money). And some of them just aren’t possible within the application architecture(like asynchronic programming). So you have to find a balance between them. If you can't make an application with a live update feature, then make sure that version conflicts are prevented through other means. Like a resolve possibility or perhaps a locking mechanism.
A lot of decisions on User Experience are made instinctively, which is actually a personal evaluative process based on related experience and acquired knowledge. Just don’t forget the “why” and “how”. If you are able to back-up the decisions made for improving UX, you can get an understanding with your fellow project members. And this is essential when trying to reach compromises.
Measuring success
When all the requirements and development is done, it’s time to evaluate the “good” and the “bad” of each made compromise. What comes in handy is some kind of ruler by which to measure. For this I found four factors that were originally meant for Interface Design, but also can be applied to User Experience (Thkx Mike Padilla):
- Ease of learning and memorability
- Efficiency of use
- Error frequency, severity, and recovery
- Subjective satisfaction
Depending on the ultimate use of the application, each factor may be of variable importance. For example, efficiency of use would be more important for a highly used application than for a brochure-like marketing website, whereas the reverse may be true when it comes to subjective satisfaction. Each decision that is challenged can be evaluated by judging it against each of these four factors.
Finally
Good and Bad user experience design is all about making compromises. Just keep in mind how the application will be experienced by the users. An application with a good User Experience will always be worth the extra effort. And when you do have to make compromises, just try using a valid measuring ruler. Know your future users and don’t try to let one party in your development cycle get too much influence. The best solution is to let a User Experience Specialist manage the negotiations when searching for compromises, so the outcome will always be in the best interest of those that will be working with the result the most.