Creating a software product - are you doing it wrong?
The goal of software, be it web, mobile or desktop applications, is to help achieve business goals. However, without achieving people's goals, and with that the ones of software users, it is very unlikely that the business will achieve its own goals. This is why software projects should start with design, not programming. User centric design, that is, where accent is on understanding users and especially their activities. Not to diminish the value of other aspects, the quality of user experience is the most important.
You would think this is obvious? Absolutely not. The fact is that a large number of software projects neglect design completely and this inevitably brings about bad user experience. After posting Designing User Interfaces For Business Web Applications on Smashing Magazine and a large number of comments and e-mails that followed, I realised that problems I faced are still there and little is done to understand them and solve them. And, what are these problems?
The first problem is competency and responsibility. Most companies don't have a person in charge of making design decisions. That's what Bill Buxton calls Chief Design Officer (CDO) in his book Sketching User Experiences. Instead of having a person who'll make decisions and understand why they were made and what the consequences are, design is often everybody's and nobody's responsibility.
The next problem follows on to the first, and this is the work process. Although it is very ungrateful to generalise things, we could say that the process of developing a typical software project is oriented almost entirely at its functionality. By this I mean implementing business requirements. The problem is that business requirements describe only what and how the system should do (business rules), leaving out the fact that software will be used by people.
The process looks something like this:
- Project starts by gathering requirements and writing a specification
- Based on this, resources are planned and estimates given
- Further decomposition happens to get from abstract to necessary implementation documentation
- Backend and frontend are implemented
- Designer is found to create a "theme" for the application (when I hear something like this my left eye starts to twitch)
- Software is delivered (with a huge delay)
- Users start using the software, after which starts a series of usability issues, complaints and a lot of work for support staff
- After a while, it turns out that only 20% of delivered software is being used and sometimes it's not even used at all.
Although I've caricatured a little, you get the point. Many of us have taken part in this type of projects. Where are the users? Where is the interaction with people? Software is used by users and not analysts, project managers, or developers. Most project stakeholders create the software to suit their own needs i.e. for themselves. Most developers, for instance, just don't have the knowledge necessary to design a UI for humans. Just because it makes technical sense, it doesn't mean that it will help user experience. The technology is there to help people and not to make them its slaves.
To avoid these catastrophic scenarios, it's necessary to change the whole idea of software development, root and branch. So, instead of creating a "clean, professional and good looking theme" for a completed software it is necessary to design the behaviour of user inteface before the software is created. This includes various aspects of design, from determining the scope to interaction and interface design. Thus, decisions on user interface should affect the behaviour of the system and not vice versa. Technical contraints and business rules permitting, UI behaviour should not be stipulated by system backend implementation.
As Jessy James Garett says in his book The elements of user experience:
Everything user experiences should be the result of a conscious decision on your part. Realistically, you might have to make a compromise here and there because of the time or expense involved in creating a better solution. But a user centric design process ensures that those compromises don't happen by accident. ... It can be easy to fall into the trap of thinking that we are designing our site for one idealized user - someone exactly like us. But we aren't designing for ourselves; we're designing for other people, and if those other people are going to like and use what we create, we need to understand who they are and what they need.
This is certainly easier said than done, because as I have already said in the SM article - a good software product takes harmonization between needs and goals of both the business and the users. To achieve this you need to harmonize management, design and development. Otherwise, we come to a situation where everybody is frustrated, from developers and managers to clients and users.
Since this subject is somewhat neglected, I'd like to hear your experiences and opinions.
More articles in
Blog archive or
elsewhere