Is there an interaction designer in the house?
I can recall a certain batgimp of my acquaintance once expressing the hope never to have to use any interface designed by me. An understandable aspiration, given my preference for muscle-memory keyboard shortcuts and/or complete programming languages in a UI, combined with my extremely low patience or empathy with those less me than I.
Nevertheless, it would appear that this very fate is about to befall some 200-odd unfortunates, who will be attempting to manage subsidised childcare through a cron-designed web interface.
A UI designer I am not (see above), but I do appreciate that there are good and bad UIs, and that the good ones don't happen by accident. And I have no intention of designing another bad UI. So I could use some advice.
As I said, this is going to be a web app. My requirements are defined by a set of reasonably detailed usecase descriptions for the system, derived from the crappy fat-client app it will be replacing. The question on my mind is - what next?
What I'd like to do next is fill in the details of how these usecases will work at the level of webpages - What does my user do to kick off the usecase, what information do I need to put on the screen, what data do I want the user to enter, how do I deal with errors, etc. In fact, it appears I want to design some interactions.
So how? How do I describe all the crazy shit a user might want to do, and find a way to do it all in an efficient, consistent and reasonably obvious way? Then, how do I accomodate the twenty-five other things the user wants to do, that I find out halfway through the development cycle, without breaking that efficiency, consistency, and obviousnessness?
I've never been able to figure out what it is interaction designers do in the afternoons, but I suspect that thinking about such problems might be part of it. At least in between naps and Kermit-abuse. So it stands to reason that there are Ways Of Doing These Things. Some kind of meta-model for the structure of an interface and the paths through it, maybe? Any pointers to this kind of stuff would be most gratefully received. Heck, I'd even read it!
Nevertheless, it would appear that this very fate is about to befall some 200-odd unfortunates, who will be attempting to manage subsidised childcare through a cron-designed web interface.
A UI designer I am not (see above), but I do appreciate that there are good and bad UIs, and that the good ones don't happen by accident. And I have no intention of designing another bad UI. So I could use some advice.
As I said, this is going to be a web app. My requirements are defined by a set of reasonably detailed usecase descriptions for the system, derived from the crappy fat-client app it will be replacing. The question on my mind is - what next?
What I'd like to do next is fill in the details of how these usecases will work at the level of webpages - What does my user do to kick off the usecase, what information do I need to put on the screen, what data do I want the user to enter, how do I deal with errors, etc. In fact, it appears I want to design some interactions.
So how? How do I describe all the crazy shit a user might want to do, and find a way to do it all in an efficient, consistent and reasonably obvious way? Then, how do I accomodate the twenty-five other things the user wants to do, that I find out halfway through the development cycle, without breaking that efficiency, consistency, and obviousnessness?
I've never been able to figure out what it is interaction designers do in the afternoons, but I suspect that thinking about such problems might be part of it. At least in between naps and Kermit-abuse. So it stands to reason that there are Ways Of Doing These Things. Some kind of meta-model for the structure of an interface and the paths through it, maybe? Any pointers to this kind of stuff would be most gratefully received. Heck, I'd even read it!
posted by cron | 10:48 p.m.
<< Home