A few weeks ago, Cary Millsap sent me a link to The Fable of the User-Centered Designer. It's short and an enjoyable read, so I suggest you download a copy and read it before continuing. For those who don't follow my advice, here are the three secrets of user centered design:
1. Early and continual focus on users and their tasks
Spend time with the users to gain an understanding of their environment, how they work and which tasks are critical to their job function.
2. Empirical measurement of user behavior
Don't ask a user what they think of the design, watch them use it and measure the usability of the design. Measure how efficiently they are able to complete tasks with your tool.
3. Iterative design
Good design must be an iterative process which will result in many, many possible designs, each of which needs to be tested and retested for usability. Use prototypes (mock-ups in my lingo) to measure usability before beginning to code. In the fable, they begin with paper prototypes and move to electronic prototypes. Your design should be stable before you begin the serious code work.
The fable makes some excellent points about design, and how design teams get it wrong by focusing on just the visual appeal or just the technology, losing site of the real goal which should be a product that makes it easy for someone to do their job. IT tends to assume we know who the users are and how they will use the tool, but that can be a huge mistake. We also forget that other people are not like us. They may love the business function they perform with the software but they don't want to spend unnecessary time dealing with the tool or figuring out how to make it work.
To put it in perspective, I'm a database geek. I like data and columns of numbers. I like figuring out how Oracle solves an optimization puzzle or how the OS or hardware should be configured. I like experimenting with different approaches as I work. Ask me to do those same things with my desktop solution and you'll piss me off. I hate having to deal with desktop software and updates - that's why I use a MacBook. I hate waiting for graphics to load or making a document look pretty - I'd rather work on a Linux box and use vi. Just because I'm interested in one aspect of technology that doesn't mean I'm interested in all of them. More importantly, just because I'm interested in the database and the guts of the data that doesn't mean my users are. They just want their data returned accurately and quickly. Everything else should be transparent to them.
Reading this fable reminded me of a few events in my job history. I started my career in industrial engineering and manufacturing, but from the beginning, I tended to get all of the system related responsibilities, mostly because no one else wanted them. Over time, I became the translator between IT and manufacturing and those dialogs were very much like watching a gathering of the United Nations. A meeting would include representatives from various manufacturing teams, IT project leads and designers, and me. The manager from the electrical development team would describe a task that his guys needed to do, and the IT people would look at me and I'd explain it in their terms. Then they would describe their solution, and I'd translate for the electrical guy. It was literally as if they spoke different languages. We didn't start out doing it this way, but after several projects failed to provide what was expected, management altered the format. The UN-like meetings took longer than the old style specification meetings, but in the end, the development cycle was faster as there was less rework. Plus, everyone's blood pressure was much improved and when you work with older manufacturing guys, that's important. (There were more than a few heart attacks on the premises during my years at Lockheed.) The communication gap is probably not as wide in all business functions but if you take the time to watch how your users actually work, you might find that what they actually mean is not always what you thought they meant.
I've implemented and supported both PeopleSoft and SAP systems at different companies, and the differences in user adoption of those products illustrates user centered design perfectly. My experience is with the Human Resources and Student Administration modules of PeopleSoft, and the functional users adored PeopleSoft. While there was usually some resistance to change in the initial implementation, once they started using the tool for part of their work, they wanted to do all of their work in PeopleSoft. I don't know how PeopleSoft did their usability studies, but they did something right. PeopleSoft seems understand how the HR user works, although I still find most HR people baffling - they are the antithesis of the manufacturing types I was used to.
With SAP, my experience has been the exact opposite. Users hated to interact with SAP and would go out of their way to avoid it. They would hide some aspects of their job functions out of fear that someone would decide it needed to be coded into SAP. While there may have been an occasional request to add a module, it never came from the end user. It came from a manager or a different team that needed to be able to connect another data point.
The PeopleSoft screens were 'friendlier', but I don't think that's the primary difference in user adoption. When you build a tool that makes is easier for people to get their work done, they will use it every chance they get. Yes, there are all sorts of theories about resistance to change and users being unwilling to learn new methods, but the reality is users will change if the tool helps them work better. If users are not integrating a new tool into their tasks, then the tool sucks. It's really very simple.
Perhaps the most significant point that the fable makes is that users can't always tell you want they need because they don't know what is possible. If they've been making do with spreadsheets, how can they comprehend what is possible once their data is in a relational database connected to other related data sources with a usable front-end application? The fable references the famous quote from Henry Ford: "If I had asked my customers what they wanted, they would have asked for a faster horse." How many other products have been developed in the last 100 years that we can't live without but never comprehended could have been built?
Now for the 'constructive criticism' portion of our program. Like many of the new development theories and methods, the fable talks exclusively about the design of the user interface. There is no mention of designing for data usability or making sure the architecture is scalable. However, if the data source is not usable, the iterative process will be extremely painful. And by the time you get to the electronic prototypes, you'd better have some real data in there or your usability studies will be flawed. Once users can see what can be done with the data, that's when they can start giving you valuable feedback on what they need and that's when they will change the design on you. Remember, users can't always tell you what they need because they don't know what is possible until there is something tangible in front of them. But if the data has been structured into a solid 3rd normal design, the presentation of that data will be adaptable to their changing needs.
I'm starting to believe that it is safer to assume that every new development method should be considered a completely separate process from the database design. Seems like a user centered designer would recognize that the data structure needs to be usable so the information can be assembled and reassembled as the user needs to see it. A user centered designer would know that it's important to have the right architecture, so the tool performs quickly and efficiently. After all, if it's important to measure the amount of time it takes for a user to complete a process, it's also important that the user doesn't have to wait for the screens to populate. (although that's not something you'll see with the paper prototypes) I do know that a slow system will not have users flocking to use it, so a non-scalable system will have a low rate of user adoption.
The 'Agile' word is also referenced at one point in the fable, but I've come to the conclusion that anyone who uses that word needs to include a definition. Everyone seems to do Agile differently: it's amazing how many different versions there are just within my current department, much less in the entire development world. It's like the word 'music'. The music I listen to may be very different than the music you listen to and assuming we both like the same music would be as silly as assuming we both use Agile the same way or that we know what the user needs based on words. We need to watch and understand the user's actions if we want to be effective in software design and development.
Ok, that's one down but it's already 2:30. I'm still aiming to get that second post up but I've got a few other things to do first.