Design Last Design « Designing Interactive

Jan 06

Design Last Design

Agility comes from your ability to rapidly gather feedback about the software you are building, and to react quickly. This is especially true during your initial build phase.

Interface First Design

I’ve always been a supporter of Interface First Design. To your customer, the interface is the product. The customers needs are all defined by the way they interact with your product. This is why we have always encouraged designing the interface before writing any code. This keeps developers from over-engineering features and ensures the customer gets what they expect from you.

However, I often find myself over-designing. I waste a lot of time designing things that will be deleted in future iterations.

Introducing Design Last Design (DLD)

Recently, I’ve been experimenting with what I call “Design Last Design.” Essentially this means we sketch out a user interface in the beginning, as we always have, but we don’t pretty it up. We build the whole application in greyscale with standard fonts, and boxes, but nothing pretty. Near the end of the project, we wrap it all up with graphic design. The interactions are all still designed up front, but the graphic design is laid on at the end. We don’t waste time on graphical details which are not yet important.

Focus on the customers needs and build a crude UI which fulfills them. The UI can, and probably will, be ugly. That’s ok, as the purpose of this step is to gather feedback on the interactions, not the graphic design.

It feels like you are building a wireframe in OmniGraffle or Visio, except with real behavior underneath.

Our customers have appreciated this process, since it makes design changes easy. We can juggle elements around the page or move things from one page to another. The whole application is working and can be played with. We can do some pretty intensive usability testing on these interfaces too.

The goal of this process is to collect as much feedback about the interactions of the application as possible. When customers know that design is not-finished, they are more open and honest with their comments. The cost of implementing change is less. When we are ready, we can start to lay a graphic design on top of it.

The quality of the finished product is always better than our previous methods, without an increase in development time.

About Josh Walsh

Josh Walsh is a Managing Partner at Designing Interactive. He's also an award winning designer, author and speaker on the topics of User Experience Design, User Interface Design and Usability Research. You can follow him on twitter at: @joshwalsh

6 Comments »

Dave Goerlich

I’ve seen first hand how effective this is. Meetings with the client remain focused on the interface and the underlying business process, rather than getting bogged down discussing the merits of #3366ff versus #3366fe. Even internally I’ve seen us remain much more focused on the core of the application. In the end, I’m confident this is going to be a very successful experiment!

January 6, 2010
Joe Fiorini

Interesting method. I highly recommend Jeff Patton’s “Twelve emerging best practices for adding UX work to Agile development” (http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html)for further reading. It’s somewhat similar in that the pattern he’s noticed is having low-fi mockups for as long as possible before producing something final.

January 9, 2010
Josh Walsh

Joe – Yes, I’ve read that article and really enjoyed it.

The main difference here is that my whole user interface stays lo-fi until the end of the project rather than just in the planning stages. While you can get some great feedback from lo-fi wireframes in the beginning, the best feedback comes from interacting with the real mccoy. By staying lo-fi through the initial build, we can use that feedback to make changes inexpensively.

Thanks for the comment.

January 10, 2010
Danny

Although I confess that I am the first to let the client dictate the process (often a huge mistake), I really like the “Design Last” model. Old habits die hard, but this one might be the resolution I was looking for this year. Thanks Josh!

January 12, 2010
Matt Becker

Awesome. Awesome. I love hearing other folks using this method and having it work well for them. I’ve taken the same approach with great success – giving clients grayboxes to start out with and design around the site’s content, gather feedback and work on its structure and layout. It also aids my process of doing more information designing in the browser, which helps cut down on the time making adjustments later.

I’m amazed you were able to keep this so short, because I could go on about the benefits of this method forever. And probably will, now that I think about it.

Great article, Josh. =)

January 15, 2010
Josh Walsh

Matt. – I’m really interested to talk to you some more about this. We’ve had awesome success with it so far.

January 16, 2010