I routinely witness two perennial problems in the design of software-driven products:

1. Designers miss opportunities for the computer to relieve people of boring and tedious work, which would enhance the experience of the product.
2. Designers miss latent failure modes and performance bottlenecks that can torpedo the experience of the product.

Wait. What?

Per the first point: If you can define a business process with enough specificity, no matter the scope or scale, you can turn that process into a machine. A computer is a machine that runs definitions of machines. Therefore, any well-defined process has an equivalent definition in code. This is the difference between performing an activity, and performing an activity that performs an activity. It can be as simple as directing the machine to fetch information to auto-fill a form or collapsing a bunch of mouse clicks into a single batch operation, though there are considerable opportunities for more nuanced ways a computer can do its share of the work.

Per the second point: A failure mode is a specific concept from engineering that considers not only when a system fails but how it fails. Different failure modes entail different responses, and developers often need specific guidance around what information they should provide to users to correct them. This is the difference between providing your users with the most intelligent route to help them get on with their business or simply an error message that tells them to please try again later.

Now, enough flight hours logged as a user experience designer will enable you to catch some of these conditions, but you probably won't catch anything close to most of them without a solid understanding of how computers work. You probably have access to developers, but when push comes to shove, they tend to be more concerned that their code doesn't crash than the minutiae of how it interacts with people. Which is fine, that's their job. Besides, to do this kind of work effectively, a person needs to understand in excruciating detail how the medium works without having to account for its implementation, and it helps to be able to speak the languages of designers, businesspeople and geeks. In a word: me.

Who You Are

Hopefully you're somebody in the business of making software, software-driven devices or websites, and you're interested in enhancing your product. If you aren't, you are clearly somebody who is going to notify one of these people right away.

How This Goes Down

• You send me your design material, preferably around the point you've got something significant to send but not so far in that you've invested in an implementation.*
• I plunge into the pile, make adjustments and recommendations to the design for task automation and graceful degradation and send those back. If appropriate I might even write a prototype to help communicate concepts to developers. You know, because I can do that.
• You send me money.
• Repeat as necessary.

The Result

Products that aren't a minefield of hidden opportunities to drive people nuts. Products that optimally divide labour between (fun and interesting) people and (boring and repetitive) machines. Products that turn people into fans. And a pony†.

If You Act Now

Well, I'll get started on your product sooner. And that's probably good, right? Time-to-market and all that? So get in touch with me through any one of the litany of channels you feel most comfortable doing: email, Skype, Twitter, carrier pigeon, etc.

Looking forward to hearing from you, and remember: no interaction is the best interaction.