There comes a time in a project (hopefully near the beginning) when you’ll have to sit down and level with your developers. You’ll tell them all about HCI and user-centered design, and all the wonderful ways that grown-up projects behave. And although this talk may be difficult - heck sometimes it seems like we’re speaking a different language - it will be critical to your team’s growth and success. So how can we, as HCI people, talk about these things so that developers will understand and be responsible?
Here’s some suggestions:A. Developers are logical.
They love puzzles, and love figuring out the logical semantics of a system. HCI is a mystery to them because they see the more subjective aspects of it (e.g. visual design), and conclude that the whole discipline is touchy-feely and generally subjective/illogical. One aspect of UCD which might help them shed this notion is the concept of Modeling Work. For an excellent discussion of work models, check out Chapter 6 of Contextual Design by Beyer and Holtzblatt.
Plenty of programmers have created models and simulations before, so this process feels logical and testable to them (of course, because it is). Some examples of models of work:
1. artifact model tracks the lifecycle of documents and other objects which users employ to complete their work
2. the flow model describes the flow of communication involved in getting work done
3. the cultural model diagrams the influences of company culture on decision making
It sounds silly, but one great thing about these models is that you get to draw boxes and arrows. To a developer it kicks the legitimacy up a notch, and it also creates an artifact that everyone can discuss and draw on.
B. Developers jive with numbers.
Whenever your usability tests can generate real numbers which indicate statistically significant improvements, you should share the results with your developers. They can easily appreciate this kind of improvement the same way that a visual designer can easily appreciate improvements in color, form and balance.
Also give them real numbers as guidelines for system responsiveness. Is it acceptible for a certain task to take 20 seconds? If not, explain how the user’s expectations for responsiveness will inform the design.
C. Developers can understand the human as system component.
From the system engineering perspective, the human is part of the system. You may think you are building an “application that does X”, but you are actually creating a system where application and human interact to accomplish X. This is an important distinction. Some devs see the application (and esp. architecture) as the supreme goal and complain about the ‘lusers’ messing things up. But in the context of the overall system, action X will never be achieved unless the interface between human and computer is properly bridged.
Though KC has disagreed with me already on this, I think that its fair to describe the human as sort of a specialized programmatic interface. The application being developed must be able to speak our language, similarly to how a dev must adhere to APIs to make chunks of code play.
The human is a special machine which has limited RAM (7 +/- 2 objects can be held in immediate working memory), has inherent latency (time to move muscles is clearly bounded), parses data according to rules (the way we read, the way our eyes scan), and recognizes a library of symbols (language, icons, visual hierarchy). Explaining HCI concerns to a developer in this way helps them to start incorporating people in their mental model of a successful system.
Until the human is included there are things that just won’t make much sense to a dev. For example, lazy-loading. Let’s say it takes 3 seconds for the full results of a query to come back to a user. To the dev, the code is clean and 3 seconds is the fastest we can get the full results back. Now here comes some HCI people saying we need lazy load — but this will make the code more complex and the total time to get all the results loaded will jump to 5 seconds. Ug.
But now include the human in system. With lazy-loading, the user gets 1/10 of the result set in half a second and feels like the system is responsive. They are able to keep busy with that data while the rest of the results come in over the next 4.5 seconds. When the human is added the picture, it becomes clear that lazy-loading does not slow things down, in fact it is akin to pipelining in processor design, and has the ability to speed things up considerably.
Another way to talk to developers so that they understand is to show them that you come in good faith.
This can be achieved by handing out bananas as they charge into the room and begin swinging around frantically on the monkey bars and tyres you installed specifically for the meeting.
Feedback from the meeting can sometimes also be a problem. I suggest the installation of two big buttons in front of each ‘chair’. Ask them to push the GREEN button when they understand (or are happy) and the RED button when they dont understand (or want more bananas).
One thing to add about this post: It is not that developers are deficient in some way which makes it necessary to talk down to them. It’s just that they have a different set of concerns, so certain aspects of HCI and the HCI process will seem more important/valid to them.
To contrast, if you were relating the value of HCI to a marketing person, then you might focus your time on the visual aspects, the ease of use, and how HCI improvements would drive increases in market share. You might do a side by side analysis of key players in the market. None of this should be considered to be “talking down” to the marketing people.
The reality today is that HCI needs to wear many hats to suceed. Historically the channel of communication between developers and HCI people has been quite rocky, so that’s what I chose to write about.
Are you kidding? I have been a developer for about 18 years and have never had a problem in tayloring the userinterface to the target population.
Admittedly sometimes useability is a tradeoff.
“When do you want this to be ready?”
You can continue to polish a system ad-infinitum.
Give developers a bit of credit. they are system users two. It may be the case that with new developers who have not “been around the block” a bit you can have problems, but even so…
I really did not like the reference to monkeys when talking about development teams…
“Are you kidding? I have been a developer for about 18 years and have never had a problem in tayloring the userinterface to the target population.”
That would make you in the minority, Peter. Unfortunately, a comic strip that talks about HCI is bound to end up preaching to the choir more than it is to the uh … less enlightened.
Also, the monkey comment was a joke comment which neither Tom nor I had anything to do with.
“Give developers a bit of credit. they are system users two.”
I think the “we are users, too” is really part of the joke of the strip. You are, but you aren’t. Even as a less technical expert, I don’t consider myself “a user”. It really depends on what you’re building of course but the point is we need to build for the target population, as you mentioned, and not assume that just because we can use it, so can other people.
“…have never had a problem in tayloring the userinterface to the target population”
oh boy. like he really knows his users.
thank you for proving the point of the cartoon so acutely.
OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?