Design vs implementation, from Marty Cagan

An excerpt from Inspired: How To Create Products Customers Love by Marty Cagan (a founding partner of the Silicon Valley Product Group and previously senior vice-president of product management and design for eBay, vice-president of product at AOL and Netscape Communications):

One thing that many teams try to do in parallel – but should not – is user experience design and implementation.

There are several reasons for this:

First, there is a dynamic in software teams that is important to recognise; once implementation begins, it becomes increasingly difficult to make the fundamental changes that will likely be necessary as you work through your user experience design ideas.

Partly this is technical – engineering teams must make some early architectural decisions based on assumptions about the requirements and designs in order to make progress. These early decisions are important and have big consequences.

Partly, this is psychological – there is a mindset that takes hold once the team shifts into implementation mode, and it’s demotivating to go backwards.

Partly, this is practical – the clock is ticking, and rework and churn just compounds the pressure the team is under. So even though methods like Agile advocate embracing change, you quickly find that some changes are much more welcome than others.

Second, user experience design deals with the very difficult question of both usability and value and, in order to come up with a product that is both usable and valuable, you will need to try ideas out – early and often.

One common response is “We’ll get feedback in beta,” or with Agile teams, “We’ll test the idea out at the end of the sprint.” Unfortunately this is far too long to wait to test out an idea. A good user experience designer will want to try out dozens of ideas and approaches in a matter of days, and the thought of waiting even for a two- to four-week sprint would be debilitating as the frequency is an order of magnitude too slow.

[…] Fourth, while it often makes excellent sense to break up a release into several iterations to implement (this reduces risk, improves quality, and eases integration) a user experience is often not something that can be designed in pieces. You have to look at the user experience holistically – it has to make sense to the user at each release. While it’s easy to “stub out” software that’s not yet available, it’s not so easy to do the same for the user experience.

If you enjoyed this article please share it with your friends and colleagues.

Leave a Reply

Your email address will not be published. Required fields are marked *