Josephy Cooney has written about avoiding the unfortunate “Developer UI” condition painfully known to software developers and users alike. His post focuses more on development process and the ad-hoc methods that can allow hastily conceived developer utilities to become a permanent part of shipping products. He gives some guidelines to help programmers avoid creating overly cumbersome user interface elements for their own strictly utilitarian purposes, lest these things grow malformed legs and end up half-ambulating around the application forever.

My own struggles with Developer UI are a bit different: I find that managing a group of only developers—myself included for our purposes here—makes user interface design difficult. We never have a problem exposing cobbled-together utility code and having people fall in love with it, but we do have fairly typical problems doing good interaction design, being too small of a shop to have a specialist UI designer on the payroll.

The problem is that good developers are trained to take the bewildering array of particulars in their problem domain and abstract them and systematize them into something simple and elegant. (Another good, if indirect, reason for developers to be realists: universals are your stock in trade.) This, combined with the typical developer bias towards utility over beauty, can create some pretty cumbersome human interfaces. My typical first pass will result in a UI that is beautifully abstracted to expose the deepest conceptual core components of the system in such a way as to be completely inaccessible to any normal person who has not thought about the product for as long as I have. Which is to say pretty much everybody else in the world is going to think it’s trash.

The trick is to design user interfaces to work in a way that most people will expect, rather than the way a developer would calculate. The application model—the view of the world exposed by the program, plus its relevant data—ought to coincide with the user model, or the view of the world and its relevant data that is natively and unreflectively assumed by the user. Hence deep knowledge of the application’s internal model is a huge barrier to effective UI design; it is a vast body of facts and mental habits which must nearly be forgotten in order to get oneself into the user’s mind and make a good guess about the model residing there. This involves some disciplines which, while not in any way antithetical to software development, are not really rewarded in the field either: things like the ability to see things through eyes that are very different from your own or the ability to step back, blur your vision, and get a good view of the big picture.

It’s like being a camera that can switch effortlessly between a macro lens and a fisheye lens. Anyone who can do this well has a shot at creating outstanding software which is both easy and pleasurable to use—which should be the among the highest aspirations of people in this profession. If you can only manage one of those lenses, you’re either stuck in a cube writing code or in a marketing department being enthusiastic for the rest of your career. Not that there’s anything wrong with that, as Seinfeld said, but it’s nice to aim higher.

h/t Style Gala

• 
• Posted by Tim on Monday, December 4, 2006 at 10:20:14 am PST
• Category: Technology, Philosophy
• Comment RSS Feed