Friday, September 4, 2009
Fixing process problems in the UI
Most experienced UI designers will have seen this at least once: a client asks for a new online self service application and insists "we really want a lot of people to use it." Hey, when a client cares about usability of the application you're designing, that's a good thing, right? When you do your up-front analysis you discover that their existing process for servicing customers is awkward and unsatisfying for its users. You point out, reasonably, that in order to create a good self service application, the client needs to tweak its service process. "No," you're told, "we can't do that. You have to work with what you have." And then the kicker: "Just think outside the box." The client rep you are working with either isn't in a position to change its process, or doesn't feel the need to. You're stuck automating a bad process, and your design spirals down into a series of design anti-patterns, workarounds, and random attempts to fix the workarounds. And everyone loses in this scenario: the client, the customers, and you for delivering a bad application.