Possibly random thoughts of a oddly organized dba with a very short attention span


user centered design

It's the day before the new year and I have two topics related to development that I am hoping to complete today to wrap up 2009. Then I plan to refocus this blog on its originally intended topic - measurement. I can't promise not to wander off topic again but I will do my best.

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.


Derek Neighbors said...

Being an agile software developer that has to work with visual/graphic designers regularly it's always interesting to hear various approaches. Thanks for taking the time to share this.

Toon Koppelaars said...

This sentence resonates with me: "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."

That statement also implies that "changing needs" are for the majority always impacting the user interface (UI) layer. In much fewer cases are the "changing needs" such that they require a change in the database design. But then again, suppose they do require a change in the database design; if that design was setup in a solid 3rd normal form manner, then making changes to it is usually an easy job.

Also: "We need to watch and understand the user's actions if we want to be effective in software design and development."

Understanding the endusers tasks is paramount, yes. The way I approach this is, once I (finally) understand these tasks, I try to become the enduser. And being the enduser, I ask myself: how would I ideally like the UI to be designed such that it helps me perform that task in an efficient way. Knowing that the way the data has been organized (in the underlying 3rd normal form design), can be (and in may cases, is) completely different from the way it will be presented to me to interact with, in the UI.

"Helsinki" Toon

Robyn said...

Hello Derek,

I'm glad you liked it and am very pleased to know that I still have agile software developer readers. I was afraid they might come to the (incorrect) conclusion that I dislike all things about Agile. Thank you for reading.

Hi Toon,

I think we need a Helsinki flag, or at least a rallying cry. Some system components, such as the architecture and the data model, need to be designed with a long term vision, so they can be used with agility later in the development process. Perhaps we can build Development Nirvana in Helsinki by implementing architecture and databases with detailed, advance planning toward the long term vision, and then using a user centered, agile process to develop interfaces. Now we just need that flag :)

Becoming the user is a good approach, as long as we make certain we understand their tasks as you noted and I think observation should be part of our learning process. And yes, the third normal form seldom looks anything like the user interface, which has resulted in complaints from the java team in the past. There's been no denying the performance and adaptability improvements though, and there is always the option of a view to make it easier for the developers to visualize the screen data.

cheers ... Robyn

Cary Millsap said...

I'll preach to the choir here, but I think two sentiments deserve singling out:

1) I believe that software is much better when the design process begins with the end user, not the data model. By "begins," though, I mean the purely temporal sense, not the biblical sense: that the first step in the design process should be user immersion, not that the data model is second in importance.

2) Poorly designed data is a crippling mistake in a project. The data model needs to be elegant and well-factored (e.g., 3NF), just like the code that the developer will craft to intermediate the user's experience with the data.

Search This Blog


My Blog List

disclaimer ...

The views expressed on this page are mine and do not reflect the opinions of my employer, former employers, other associates or the opinions I may hold 3 days from now.