A respectful disagreement with some good friends

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?

  1. Rodrigo said:

    I completely agree. Based on your experience, what do today’s dev tools lack in order to give good support to both prototyping and actual code development?

  2. I couldn’t agree more with you. It’s very refreshing to see this viewpoint from more people in the UX field. I work very closely with my developer teammates, for exactly the reasons you list. We jump into prototyping real UI almost immediately, in many cases. And, in my opinion, technologies have become so approachable and flexible (Flash/Flex, WPF/Silverlight, etc…) that you really don’t have much of a reason to fall back on only having mockups or paper prototypes.

    There’s always a place for Photoshop mocks, especially when quickly iterating through aesthetic approaches. But for interaction models… Nothing beats the insights you gain through iterating on an actual prototype. Both in terms of what you learn while actually making it and playing with it, but also how early and often you can put it in front of people and enjoy real observation.

    I have done paper prototypes before. I don’t plan on ever doing them again. They had a place, in their time, but for me, that time has past.

    That being said, one of my favorite design tools is still my whiteboard… ;) (But that is also a big indication of workflow – sketches are ephemeral. Often times, the design IS the prototype.)

  3. amy said:

    I know this is the wrong place to post this, but I don’t see another place. I couldn’t find the “subscribe to RSS link.” Could you help me out?

  4. Sometimes one needs to make an extreme statement in order to push the pendulum away from the opposite extreme at which it is stuck. The reality is that programming at the start is the norm, and has been the status quo from the beginning. And it has failed. Leaping in and prototyping in code from the start has shown its value through the systems that it has produced. It has given us an industry which is incapable of developing new products internally from scratch, and made the industry almost completely dependent on mergers and acquisition for growth. And for every start-up that has succeeded in using this approach to get successful products to market, there are 100’s, if not 1000’s that have failed – mainly due to following this old dogma.

    Of course, balance is needed, and programmers should be part of the design team from day one – as should business people. But if you hang your project’s hat on starting in on prototyping, statistically speaking, your prototypes will always evolve into your product. You will explore far fewer alternatives that you would using a design-based approach, and at best, you will get a competent implementation of a sub-optimal design.

    Personally speaking, I invested too much energy, time, and sleep deprivation in graduate school in computer science to waste the resulting skills on second rate designs.

    Programming is essential. It is just not sufficient. And, until we make a strong break from the past, we will just proceed into the future using the same old techniques at worst, or minor tweaks, at best. Our users deserve better, as do the skills of the programmer.

  5. Honor to have you comment on my blog Bill – like I said, I have a ton of respect for you. I am also know for making extreme statements to make a point every once and a while (okay, maybe more than once and a while)

    I was more tweaked with Forrester for not putting context around the statement – I am in total agreement that technology has basically ignored design (and even worse, they have largely ignored the end user). But I have also been a part of many projects where we were brought in to implement a design that another team has created, only to find out that the designers never considered technological challenges.

    I guess where the pendulum sits has a lot to do with perspective – if we are working with IT or a system integrator, we do not see nearly enough thought put into design; if we are working with marketing or a creative agency, we do not see tech involved soon enough

  6. Jonk said:

    I couldn’t disagree more. Obviously your projects are structured so that developers hold critical positions and are terrified to relinquish them. A good UX diesigner/architect would sort most of these initial problems, including *gasp* the prototype, allowing the developers to get on with buiilding a fantastic solution. That’s not to say the dev team should be sidelined – they should be involved from the start- but the issues you describe are CAUSED by not allowing the right people to handle the job. Developers and design – pah.

  7. Jonk said:

    PS – just noticed how OLD this thread is, WTF it appearing in twitter. Apologies for flogging a very dead horse.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: