Recently, my friends at Forrester Research published a great white-paper titled “Best Practices In User Experience (UX) Design”, by Mike Gualtieri. In it, Mike quotes someone who I very much admire Bill Buxton at Microsoft, author of “Sketching User Experiences,” who said:
. . . the last thing that you should do when beginning to design an interactive system is write code.
The point of this particular section was to warn program managers and development managers about the dangers of rushing into code too soon. I want to be very clear when I say this as to not be misunderstood : For most enterprises, this it the absolute WRONG thing to do.
In the last 5 years, we have developed over custom 250 applications, mostly for the Fortune 1000’s – and in every circumstance where we were not allowed to start coding early, we have experienced (to put it mildly), issues.
“Why?”, you may ask… 3 reasons:
Reason #1 : Integration
We are not architecting a building, which can be easily described in blueprints and executed in a waterfall fashion. Software is a complex and adaptive system that requires constant refinement and compromise. How do you know that your designs are going to have the data structures to support them? How do you know the legacy systems can handle the newly proposed business logic and user flows. Simple, you don’t, and can’t without early technical prototypes (aka – coding very early)
Reason #2 : User Feedback
Once you get developers involved, you can have them develop prototypes to test designs for utility, usability, and desirability. Paper prototypes and design compositions just to not have the tactile feedback required to truly measure how a user will actually interact with the software.
Reason #3 : Collaboration
Truth is, our developers often come up with some of the best interface design ideas for our clients. When you remove them from the early stages of design and user research, you miss out on a wealth of logical thinking. Having the team collaborate early will often save you a TON of money and heartache.
To give the benefit of the doubt to my friends above, I will say that the way many enterprises are coding today is not always effective. They are leading a project with developers, and design is often an afterthought … I’ve heard, on many initial client calls:
We are all done with the code, its really good. But our executive team does not like the way it looks, and we are getting feedback from our beta customers that the software is hard to use. Can you guys take the next two or three weeks and skin the application to make our executives and users happy?