Haha. Chopin was huge, so it was more about the process than any specific problem.
I changed how I approached it and spent more time talking with the front desk clerks to see what they needed before I started coding away. Since then that's what I've always done, because otherwise I run the risk of wasting my effort and my customers' time (and possibly money).
baxter
· 7 months ago
Great post, it really highlights the importance of communication in systems development. Too many people forget that there is more involved than just technical skills.
Martin
· 7 months ago
Good post I did the same mistake sort of but then I read Bill Buxton's awesome book and I saw the light. The problem in software development seems to be the collected experience only goes so far back, and think because the product cost is small compared to the product cost of for say a car, prototype research gets low priority.
This is a great anecdote and totally true. I think the real dangerous territory comes when you actually use your own product - because you then think "well, I'm a user, so I'll understand what's needed." At least with Chopin, you didn't use it so didn't have any illusions about whether you needed to observe a user.
Last summer, before we launched Connect, one of the most humbling experiences was watching user testing. We put the users in one room and asked them to use The Run Around (since we didn't have any partners up yet). The developers sat in another room watching a video. We pulled our hair out while the user looked for the button to login ... we were like "it's right in front of you!" Eventually the analyst pointed it out and the user said "oh, I thought that looked like an ad." We fixed it to look like a button.
So yeah, definitely humbling and it takes a good software developer to not get defensive when given honest criticism.
BTW I second Martin's book recommendation, it's chock full of great examples and ideas.
Jesse Farmer
· 7 months ago
That's a good story. You should write about it w.r.t. your work on OpenID!
All Comments
I changed how I approached it and spent more time talking with the front desk clerks to see what they needed before I started coding away. Since then that's what I've always done, because otherwise I run the risk of wasting my effort and my customers' time (and possibly money).
http://www.amazon.com/Sketching-User-Experience...
Last summer, before we launched Connect, one of the most humbling experiences was watching user testing. We put the users in one room and asked them to use The Run Around (since we didn't have any partners up yet). The developers sat in another room watching a video. We pulled our hair out while the user looked for the button to login ... we were like "it's right in front of you!" Eventually the analyst pointed it out and the user said "oh, I thought that looked like an ad." We fixed it to look like a button.
So yeah, definitely humbling and it takes a good software developer to not get defensive when given honest criticism.
BTW I second Martin's book recommendation, it's chock full of great examples and ideas.