3 ms·

Zooming out, how does UCD protect against the basic risk of paying too much attention to the customers/users? It's like the old story of Henry Ford saying if h

Zooming out, how does UCD protect against the basic risk of paying too much attention to the customers/users? It's like the old story of Henry Ford saying if he had asked his customers what they wanted, they would have said faster horses. It's the programmers/technologists that often have the insight of knowing what the customers would want if they knew they could have it.

rjknight 13y ago
I think this is a very good point, and I think it suggests a resolution to the "antagonism" between developers and UCD practitioners suggested in the OP. In designing a system, the developers are the ones with the best grasp of what is possible, in both the positive ("here's a new way of solving this old problem") and negative ("that solution would not work because of X") senses. If the UCD practitioner is a true specialist, they will by necessity be unaware of the implementation details and even system architecture, which might cause them to either fail to spot a potential improvement or to suggest features which have poor cost-benefit ratios (even if the benefit is positive). UCD practitioners don't just ask the users "what do you want?" (I'm a developer but I have done some user research as part of UCD projects). They ask "what are your problems?" or "what are your needs?", and then create mock-up solutions which address those needs, which are then validated with the customer (think "lean startup", if it helps). It's not that different from traditional agile, except instead of "the customer" you now have "the customers" and you do a lot of your early-stage iterating in wireframes and mock-ups. This does create risks, of course. The UCD practitioner might propose designs that are unnecessarily difficult to deliver - yes, "the customer is always right", but the customer doesn't always want to pay enough to get what they're asking for, and it's the developers who will evaluate how much the designs are going to cost to implement. Or the UCDer might over-specify things, mapping out several months worth of development in wireframes that might imply major back-end work, with all of the waterfall delivery problems that entails - supposing that the back-end work takes longer than expected, would the customer prefer to cut some features or deliver later? If so, which ones? If the design reaches the developers as a single, cohesive package that cannot be broken down, we're back in waterfall-land and that's no good for anyone. To my mind, this can be resolved within the classic agile framework of cross-functional teams. User research should be a function of the team, and the decisions about what solutions to propose to the users should be team decisions. The designer should not be proposing work that will be carried out by the developers without consulting them first, and the developers should play an active role in suggesting features and solutions - offering their knowledge of what's technically possible to inform the designs. This keeps the design process grounded in technical reality but also allows for the designer to challenge the developers to come up with a way of achieving something that customers want.
mrxd 13y ago
Here are three responses to your question: 1) It's not always true that users lack insight or imagination into new possibilities. Many of our best futurists aren't technologists - Gene Roddenberry, for example. On the opposite side, programmers can sometimes be resistant to new ideas because they judge the effort to be too high for the benefit. This would be the equivalent something like "If you ask engineers, they'll tell you to buy a faster horse because internal combustion engines are expensive, hard to build and horses are faster anyway (at the beginning they were anyway)." What this misses is that speed isn't the key benefit. If you talked to users, you'd probably discover their needs are lower maintenance costs and improving reliability. Users didn't want to go faster, they wanted to get rid of the horse. 2) UCD is not about asking users to invent new ideas, architect the system or tell us how to implement it (i.e. do you want a horse or an engine?). It's about including the users' perspective in how we assess the benefits and drawbacks of a technology. Engineers tend to want to do this by quantifying aspects of the technical system (megahertz, megapixels, MTBF, softer measures like code quality), excluding a broader perspective of the socio-technical system—the system in a social, human context of use. 3) Developers are often resistant to including the users in the design process because they feel that it impinges on their autonomy, especially when it interferes with their desire to innovate. There's a little bit of... well, hypocrisy is maybe too strong a word, so let's say inconsistency in this. Developers defend their own autonomy and right to direct their own work, and rightly so. But they then argue that it should be taken away (or at least not given) to the users of the technologies they build, technologies which deeply affect the work and lives of those users. As I argue in the article, excluding users has a negative impact on developer autonomy, because UX designers are brought in, reducing and sometimes eliminating developer control, except for the most talented and insightful.

rjknight 13y ago

I think this is a very good point, and I think it suggests a resolution to the "antagonism" between developers and UCD practitioners suggested in the OP. In designing a system, the developers are the ones with the best grasp of what is possible, in both the positive ("here's a new way of solving this old problem") and negative ("that solution would not work because of X") senses. If the UCD practitioner is a true specialist, they will by necessity be unaware of the implementation details and even system architecture, which might cause them to either fail to spot a potential improvement or to suggest features which have poor cost-benefit ratios (even if the benefit is positive). UCD practitioners don't just ask the users "what do you want?" (I'm a developer but I have done some user research as part of UCD projects). They ask "what are your problems?" or "what are your needs?", and then create mock-up solutions which address those needs, which are then validated with the customer (think "lean startup", if it helps). It's not that different from traditional agile, except instead of "the customer" you now have "the customers" and you do a lot of your early-stage iterating in wireframes and mock-ups. This does create risks, of course. The UCD practitioner might propose designs that are unnecessarily difficult to deliver - yes, "the customer is always right", but the customer doesn't always want to pay enough to get what they're asking for, and it's the developers who will evaluate how much the designs are going to cost to implement. Or the UCDer might over-specify things, mapping out several months worth of development in wireframes that might imply major back-end work, with all of the waterfall delivery problems that entails - supposing that the back-end work takes longer than expected, would the customer prefer to cut some features or deliver later? If so, which ones? If the design reaches the developers as a single, cohesive package that cannot be broken down, we're back in waterfall-land and that's no good for anyone. To my mind, this can be resolved within the classic agile framework of cross-functional teams. User research should be a function of the team, and the decisions about what solutions to propose to the users should be team decisions. The designer should not be proposing work that will be carried out by the developers without consulting them first, and the developers should play an active role in suggesting features and solutions - offering their knowledge of what's technically possible to inform the designs. This keeps the design process grounded in technical reality but also allows for the designer to challenge the developers to come up with a way of achieving something that customers want.

mrxd 13y ago

Here are three responses to your question: 1) It's not always true that users lack insight or imagination into new possibilities. Many of our best futurists aren't technologists - Gene Roddenberry, for example. On the opposite side, programmers can sometimes be resistant to new ideas because they judge the effort to be too high for the benefit. This would be the equivalent something like "If you ask engineers, they'll tell you to buy a faster horse because internal combustion engines are expensive, hard to build and horses are faster anyway (at the beginning they were anyway)." What this misses is that speed isn't the key benefit. If you talked to users, you'd probably discover their needs are lower maintenance costs and improving reliability. Users didn't want to go faster, they wanted to get rid of the horse. 2) UCD is not about asking users to invent new ideas, architect the system or tell us how to implement it (i.e. do you want a horse or an engine?). It's about including the users' perspective in how we assess the benefits and drawbacks of a technology. Engineers tend to want to do this by quantifying aspects of the technical system (megahertz, megapixels, MTBF, softer measures like code quality), excluding a broader perspective of the socio-technical system—the system in a social, human context of use. 3) Developers are often resistant to including the users in the design process because they feel that it impinges on their autonomy, especially when it interferes with their desire to innovate. There's a little bit of... well, hypocrisy is maybe too strong a word, so let's say inconsistency in this. Developers defend their own autonomy and right to direct their own work, and rightly so. But they then argue that it should be taken away (or at least not given) to the users of the technologies they build, technologies which deeply affect the work and lives of those users. As I argue in the article, excluding users has a negative impact on developer autonomy, because UX designers are brought in, reducing and sometimes eliminating developer control, except for the most talented and insightful.