One of the keys to effective Agile development is having a customer as part of the development team. Yes, I really meant to say customer, not product marketing guru, executive officer, or VP of Engineering, because we don't know how to tell when a system is good for the customer.
There are a lot of reasons for this. The most prominent reason is that we're technologists, and we love engineering. That means we love to take things apart, understand how they work, and then design intricate and elegant solutions to engineering problems. It's even worse when it comes to engineering systems that will be used on (or consist of) a personal computer, because we're expert users of PCs. Therefore, we have no clue about how a non-expert user will regard the interactions offered by the system we designed.
As a result, enlightened companies have discovered that new breed called an interaction designer. And they trust the design of the interactions to these people. And what do they know? Well, they have a grasp of human psychology, human mechanics (haptics), graphic design, language and symbol semantics, and learning. An odd, but effective combination.
When all of our customers were engineers, we didn't need interaction designers. But watch out when the system is for a non-technical consumer. For an example of what happens when the engineers design the interactions, take a look at the GPS system in the Lexus. This system, in an otherwise beautifully designed car, has 13 ways to set a destination; and what's the button you press after selecting a destination, to take you there? It's GUIDE! In my vocabulary, "guide" is a noun before it's a verb.
OK, so we should not be designing our own product interactions. And that's a good reason to have a customer on the development team, so she can tell us when something looks right and feels right as we go along (every iteration). And what's our reaction supposed to be when we find out the customer wants something changed? Happy -- happy that we found out in 2 weeks that we were on the wrong track; happy that we can suggest some other possibilities directly to the customer and listen to the customer's reaction; happy that our development work, if it is allowed to continue to completion, will work the way a real user wants it to work.
And that's pretty happy.
___________________________________
John Levy consults on Agile development and is an expert witness in computer & software patent cases. He has 30 years’ experience as a technology manager at Quantum, Apple, Tandem and DEC. His book on managing technology, Get Out of the Way, is due out in 2009. Check him out at http://johnlevyconsulting.com
There are a lot of reasons for this. The most prominent reason is that we're technologists, and we love engineering. That means we love to take things apart, understand how they work, and then design intricate and elegant solutions to engineering problems. It's even worse when it comes to engineering systems that will be used on (or consist of) a personal computer, because we're expert users of PCs. Therefore, we have no clue about how a non-expert user will regard the interactions offered by the system we designed.
As a result, enlightened companies have discovered that new breed called an interaction designer. And they trust the design of the interactions to these people. And what do they know? Well, they have a grasp of human psychology, human mechanics (haptics), graphic design, language and symbol semantics, and learning. An odd, but effective combination.
When all of our customers were engineers, we didn't need interaction designers. But watch out when the system is for a non-technical consumer. For an example of what happens when the engineers design the interactions, take a look at the GPS system in the Lexus. This system, in an otherwise beautifully designed car, has 13 ways to set a destination; and what's the button you press after selecting a destination, to take you there? It's GUIDE! In my vocabulary, "guide" is a noun before it's a verb.
OK, so we should not be designing our own product interactions. And that's a good reason to have a customer on the development team, so she can tell us when something looks right and feels right as we go along (every iteration). And what's our reaction supposed to be when we find out the customer wants something changed? Happy -- happy that we found out in 2 weeks that we were on the wrong track; happy that we can suggest some other possibilities directly to the customer and listen to the customer's reaction; happy that our development work, if it is allowed to continue to completion, will work the way a real user wants it to work.
And that's pretty happy.
___________________________________
John Levy consults on Agile development and is an expert witness in computer & software patent cases. He has 30 years’ experience as a technology manager at Quantum, Apple, Tandem and DEC. His book on managing technology, Get Out of the Way, is due out in 2009. Check him out at http://johnlevyconsulting.com
1 comment:
I like the idea of having a real customer on every team. Having worked on several web startups as a content editor, I've seen processes that both included and excluded content editors from the development process. When I wasn't part of the process, I always ended up with a content management system that I jury-rigged to make useable. When I was part of the process as we iterated the design of the content management system, the developer and designer would key off off my use of the site and tailor it to what the content dictated--form followed function! But I'm surprised at how many content-driven sites go online without anyone ever having used the CMS. It's like producing and selling a car that no one has ever driven.
Post a Comment