Who owns good design?

Marshall Harrison, one of the guys behind gotspeech.net commented on my Good Speech - Bad Speech post last night.  In my post I described a particularly ugly prompt I'd seen in a speech recognition application and called on people to write better applications that keep the customer's needs in mind at all times.

Marshall has a similar soapbox as mine and one day we're going to drag them down to the Pearl Street Mall and preach together about the need to create applications that are easier to use and that, (dare I say it) People Will Love.  Marshall points out (correctly) that bad application design is often not the developer's fault.  The reason I'm doing a whole post on a comment is that a light bulb just went on for me.  The design of speech recognition telephony applications is often widely separated from the development of the application. 

By the time the developer is assigned to a project, the user interface design has often been fought over for months by people who don't have user interface design experience.  They know what they want (usually) but then they make the mistake of drawing out the design on the whiteboard, a napkin or in Visio.  Visio is the worst, because it makes the design look official and unchangeable.  People who wouldn't think of trying to tell you how to design a complex database application or desktop user interface, feel very comfortable specifying the voice user interface for you for some reason.

So what do we do?

• I think that regardless of what role you play in speech application development, you have to realize that you are signing your name and staking your reputation on how well the application ultimately works.  If you see bad design, speak up and propose a a better alternative.
• Try to get invited to the party earlier in the process.  What starts out as "we need to figure out what we want before we get the developers involved" doesn't work here so well.  The sooner we get involved the better the application will be.  Yes, it means you may have to attend some business meetings, but trust me, learning about business can be good for a techie's career.
• Find some good examples that can be backed up with concrete numbers to help make your case for good design.  Business people respond to hard numbers about saving money and improving customer satisfaction.  We built an application a few years ago for a customer who had a goal of automating 10% of the calls.  The application ended up automating 51% of the calls and customer satisfaction and CSR satisfaction actually improved.  Do you think the people funding the project listened a little closer to our silly design recommendations once they realized the impact they were having?  You bet they did!

To sum it up, we're all responsible for good design, and if we can do a better job of it this industry will grow even faster.