I was reading Guy Kawasaki's blog yesterday and came across this definition of design from a blog called Design Matters: "Design consists of creating things for clients who may not know what they want, until they see what you've done, then they know exactly what they want, but it's not what you did."
I love the design process and that statement has got to be the most concise and clear definition I have ever heard. It's also very helpful because if we take it to heart, it helps get the designer's ego out of the way. We are going through a user interface redesign right now on a project we have been working on for some time. We went over the interface over a period of months in our design team sessions and we thought we had it nailed - until we actually got it into the hands of the people who were going to use it. Then they told us it was all wrong, even though they were all on the design team that created it! It was tempting to say "too bad" and get them to use it anyway, but instead we are completely redesigning the UI.
It's easy to get frustrated over a situation like this, but this definition of design helps put it in perspective. Most people can't describe what they want, but they know what they don't want - once they see it.
UPDATE: I heard from a member of the design team on the project I reference in this post and he took exception to what I wrote here. He thought I was criticizing the team so let me clarify. Virtually every project I have ever worked on has had the same experience. Software developers do not think like "normal" people. We approach the user interface in a different way so I have found that when we build it in a way that makes sense to us, it often doesn't work for our users. Even when we get the users heavily involved in the design process, until they actually get their hands on it their feedback is not that useful. We had a lot of input on the design of this system, but it was all from demonstrations where I controlled the mouse and I knew exactly where to click (and not to click). As soon as they used it themselves, they told me it was not going to work.
That's why I loved the definition of design that is the subject of this post. It reminded me of why it's so important to not only get lots of feedback during the design, but to get a working prototype into the hands of users as soon as possible. The design team I'm working with on this project is the best I've experienced in 20 years of building software and we are producing an amazing system that is going to be an incredible service to our students.
(OK, I'll stop sucking up now and hopefully I won't get beat up at our next design meeting.)
5 comments:
this is a highly controversial issue. i am slightly offended. please don't push it.
It may be controversial, and you may be offended, but it happens. I think better communication upfront, on both parties part, is needed. I, too, am offended when a user sees a design they helped create tell the design team "they don't get it".
If the development process is not yielding acceptable results, perhaps you need to reevaluate the process.
M. Gaston:
Perhaps it was too tempting to say to the "computer geek" "it was all wrong", but that would have been all right!
The development process is yielding acceptable results because it shows that our users are taking ownership of the system. I would much rather have them tell me "it sucks" to my face while I have time and resources to fix it, rather than grumble behind my back after it is in production.
The bottom line is that a vast majority of people will not give good feedback until they are actually using the software. As long as the discussion is theoretical, the feedback will be also. That's why we try to use an iterative approach (like SCRUM) to keep a product in front of people.
Post a Comment