How do you make sure your design gets implemented right?

Hi folks,

You have finished your design. You have shown it to stakeholders and developers and it has been approved. Now the developers get to work implementing it.

But then a few weeks down the line, out pops a pre-production version of the product that looks and behaves somewhat differently than specified in your design. It seems to me that no matter how good (comprehensive, detailed) your deliverables (be they annotated wireframes, a high functional-fidelity prototype, or whatever), the thing that gets built always ends up deviating from the design (to a greater or lesser extent).

So my question is: *What do you build into your process to prevent this from happening* (or at least to minimize it)?

Cheers,

Martin Polley
Technical writer, interaction designer
+972 52 3864280
Twitter: martinpolley
http://capcloud.com/

Hi folks,

You have finished your design. You have shown it to stakeholders and developers and it has been approved. Now the developers get to work implementing it.

But then a few weeks down the line, out pops a pre-production version of the product that looks and behaves somewhat differently than specified in your design. It seems to me that no matter how good (comprehensive, detailed) your deliverables (be they annotated wireframes, a high functional-fidelity prototype, or whatever), the thing that gets built always ends up deviating from the design (to a greater or lesser extent).

So my question is: What do you build into your process to prevent this from happening (or at least to minimize it)?

Cheers,

Martin Polley
Technical writer, interaction designer
+972 52 3864280
Twitter: martinpolley
http://capcloud.com/

On 24 Aug 2009, at 10:13, Martin wrote:

But then a few weeks down the line, out pops a pre-production version of the product that looks and behaves somewhat differently than specified in your design. It seems to me that no matter how good (comprehensive, detailed) your deliverables (be they annotated wireframes, a high functional- fidelity prototype, or whatever), the thing that gets built always ends up deviating from the design (to a greater or lesser extent). So my question is: *What do you build into your process to prevent this from happening* (or at least to minimize it)? [trim]

Coincidentally this is one of the things I was ranting about to folk at uxcamplondon on Saturday :-)

I think that folk need to do three things to stop this happening in decreasing order of importance:

1) Be with the development team during development - so that you can spot issues early and fix them. Ideally be in their team room 100% of the time. If you can't do that check in at least daily.

2 Involve the developers in the design process - so that they understand the "whys" of the design. The deliverables you showed the stakeholders and developers isn't the design. The design is that thing in your head. The deliverables are a communication tool. Unless people understand the "why" they're going to miss some of things you're trying to communicate with those deliverables. Paper and prototypes are not as good at communicating as people.

2) Teach the developers more about UX principles - so they can see the difference between important and unimportant changes. That way they can understand more about when they can tweak something safely, and when they need to call for advice. Leading you free to work on the hard stuff.

Don't think about the implementation the developers are doing as a separate process from the design. Think of it as design refinement. It's a continuation of the process taking the concepts in your design and embodying them in the code, and discovering lower level abstractions that they're built on.

You need to work with the developers to make that happen well.

Cheers,

Adrian
-- http://quietstars.com

Hi,

What do you build into your process to prevent this from happening (or at least to minimize it)?

From my personal and limited experience there is nothing you can do

about it short of dealing with the development yourself. Specs won't do it and there are other surprises that surface during the implementation anyhow. Crucial point is that the specs are never complete and/or unambiguous. If they would be, they'd be so enormous they'd not be fully read or understood (I guess never is a strong word, but...). There is also hardly a way to know all aspects before doing the actual thing unless the thing being done is trivial.

Thus, as Adrian wrote already, I think you need to take part in the development phase and be present till the project is "done". That's the only better solution thus far that I've seen to work.

Best regards,

Janne Kaasalainen

Martin -

My slightly controversial view is that this cannot be prevented. That is why it is important that implementers understand about the need for user-centred design. They don't have to be experts, but they do need to know when to ask questions and to understand that subtle alterations in implementation can have big impacts on user experience.

Regards,

William Hudson
Syntagm Ltd
Design for Usability
UK 01235-522859
World +44-1235-522859
US Toll Free 1-866-SYNTAGM
mailto:william.hudson at syntagm.co.uk
http://www.syntagm.co.uk
skype:williamhudsonskype

Syntagm is a limited company registered in England and Wales (1985). Registered number: 1895345. Registered office: 10 Oxford Road, Abingdon OX14 2DS.

Confused about dates in interaction design? See our new study (free): http://www.syntagm.co.uk/design/datesstudy.htm

12 UK mobile phone e-commerce sites compared! Buy the report: http://www.syntagm.co.uk/design/uxbench.shtml

Courses in card sorting and Ajax interaction design - Las Vegas and Berlin:
http://www.syntagm.co.uk/design/csadvances.shtml
http://www.syntagm.co.uk/design/ajaxdesign.shtml

Original Message From: new-bounces at ixda.org [mailto:new-bounces at ixda.org] On Behalf Of Martin Sent: 24 August 2009 3:14 AM To: discuss at ixda.org Subject: [IxDA Discuss] How do you make sure your design gets implementedright?

On 24 Aug 2009, at 12:57, William Hudson wrote:

Martin - My slightly controversial view is that this cannot be prevented. That is why it is important that implementers understand about the need for user-centred design. They don't have to be experts, but they do need to know when to ask questions and to understand that subtle alterations in implementation can have big impacts on user experience. [snip] +N for large values of N Not controversial to me - exactly what I advocate :-) Adrian -- http://quietstars.com twitter.com/adrianh delicious.com/adrianh

That's an interesting question. From my perspective if you're implementing something Scrum* variant you should be having daily stand-ups with the people on your team who are implementing your design. This is important because when they start each particular task in the implementation they will be forced to bring it up at that particular days stand-up meeting. At that point, you'll have the opportunity to ensure that they are implementing it correctly.

A tight feedback loop is important, which is why I would emphasize the daily standup. It ensure no one just "goes off an does something." Good luck!

Charlie

On Sun, Aug 23, 2009 at 10:13 PM, Martin martin.polley at gmail.com wrote:

Hi folks, You have finished your design. You have shown it to stakeholders and developers and it has been approved. Now the developers get to work implementing it. But then a few weeks down the line, out pops a pre-production version of the product that looks and behaves somewhat differently than specified in your design. It seems to me that no matter how good (comprehensive, detailed) your deliverables (be they annotated wireframes, a high functional-fidelity prototype, or whatever), the thing that gets built always ends up deviating from the design (to a greater or lesser extent). [trim]

You build in a QA team which is connected to both Dev and Design, and thus both knows what should be there and what tradeoffs may be needed along the way.

And of course, you have Design staying active after Dev starts work, so they are aware of these shifts as they occur rather than checking in at random weeks after decisions were made.

-- Jim
Via my iPhone

On Aug 24, 2009, at 2:13 AM, Martin martin.polley at gmail.com wrote:

Hi folks, You have finished your design. You have shown it to stakeholders and developers and it has been approved. Now the developers get to work implementing it. But then a few weeks down the line, out pops a pre-production version of the product that looks and behaves somewhat differently than specified in your design. It seems to me that no matter how good (comprehensive, detailed) your deliverables (be they annotated wireframes, a high functional- fidelity prototype, or whatever), the thing that gets built always ends up deviating from the design (to [trim]

Two things have always helped to ensure my designs are always executable:

1. Make sure the project has a designated front-end developer, and be VERY close to that person (or actually BE that person, as I prefer).

2. Always be ahead of the development team. I agree with Brandon that if you're constantly behind the development team, they'll proceed without you.

Also, I prefer to build the front-end code for my projects, when there is no front-end developer. I don't believe developers make bad designers (I've been both), but I do believe it's very difficult to dedicate the right amount and appropriate attention to both the back-end and front-end at the same time.

My favorite projects have been those where the developers handled all of the controllers and models, got the info on the page, and left it to me to finish the UI. From discussions with those developers, they agreed that not having to worry about the UI was a refreshing change of pace for them.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=44968

In addition to doing the design in my group, I'm also responsible for most of the HTML/CSS — so I'll know immediately if something's not implemented to spec.

But that fundamental designer-developer chasm remains. We've developed a technology called Clickframes that lets me spec out our web apps with a simple XML syntax. In addition to my usual visual design work, I define the full interactivity of the application, and then the developers can generate their foundational MVC code directly from the Clickframes XML spec. When changes to the design occur — as they always do — I simply update the spec, and the developers regenerate the affected portions of their code. We're always in sync.

I need to be very thorough with the spec, but we've significantly decreased the number of design-to-development mishaps since implementing Clickframes.

See http://www.clickframes.org/ — it's still in "preview release" mode, so we're happy to get as much feedback as possible.

-Jon

On Tue, Aug 25, 2009 at 3:08 AM, Bryan Minihan bjminihan at nc.rr.com wrote:

Two things have always helped to ensure my designs are always executable: 1. Make sure the project has a designated front-end developer, and be VERY close to that person (or actually BE that person, as I prefer). 2. Always be ahead of the development team. I agree with Brandon that if you're constantly behind the development team, they'll proceed without you. Also, I prefer to build the front-end code for my projects, when there is no front-end developer. I don't believe developers make bad designers (I've been both), but I do believe it's very difficult to [trim]

I am glad that Jim brought up the QA team. They should have specs, scenarios or prototypes from which to build test plans. If eng knows they'll get a bug filed against them, they're more likely to implement to spec.

Designers should also be brought into the QA cycle to catch visual problems that a QA team might not see. After being trained on good bug reporting and process, of course.

Finally, I read a lot of "engineers need to learn what we do and why we do it so that know it shouldn't be changed on a whim", which is good. However designers also need to provide work that's worthy of pixel-perfect implementation. That means having some understanding of and empathy for what engineers do. Bringing them into the design process to hear from them what their concerns are about implementing is important. Being available to answer any questions or provide alternative solutions for difficult-to-impossible implementation problems is also important (I work on teams that actually assign bugs to the design team for these kinds of questions, which is great for making us a part of the implementation team).

However we must also be respectful of their time. I recently spec'd some work for a designer who was too busy, and found no fewer than 13 shades of grey, at least half of which were barely distinguishable from the other half. Spacing that was 9 pixels here, 12 pixels there... you could imagine the same kinds of problems on an interaction level. Is the engineer really supposed to implement this exactly perfectly (in which case, what a waste of time to deal with 13 shades of gray!)? Or was the designer being a bit slipshod, and expects the engineer to extrapolate? How much or how little are they supposed to extrapolate? Thinking of engineering as internal clients and being mindful and respectful of their time and skill set is a critical part of getting a design implemented as spec'd.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=44968

19 years doing it, I can't help but bring it up. Grin.

Two more things from you brought up:

1. Cultivate a UX test savvy QA person. They can see the 13 shades of gray and single pixel alignment issues at 10 paces. Let them do that consistency checking, and support them in getting things resolved.

2. Review the test plans. "Bugs" often live at all parts of the process, and QA will find them in your stuff, too. Fix them there before implementation completes and it "costs" less.

-- Jim
Via my iPhone

On Aug 25, 2009, at 10:34 AM, Audrey audcrane at gmail.com wrote:

I am glad that Jim brought up the QA team. They should have specs, scenarios or prototypes from which to build test plans. If eng knows they'll get a bug filed against them, they're more likely to implement to spec. Designers should also be brought into the QA cycle to catch visual problems that a QA team might not see. After being trained on good bug reporting and process, of course.

Wow! Thanks for all the great responses. Lots of stuff there to think about (and do something about).

The main things I'm hearing: involve devs in design and designer(s) in implementation (at least in terms of proximity, taking part in their meetings, etc.) — collaboration and communcation, be friends, build trust. Don't let them get ahead of you. And involve QA to evaluate what was built against the spec.

Thanks also for the IA- and Agile-specific advice, though neither really apply in my situation — we're building applications, so IA is only a small part. And we're not an Agile shop, so...

@austingovella: I like the part about designing in prioritized layers. Nice.

@bryanminihan: Regarding handling the front-end — doesn't this depend on the technology you're using to some extent? Example: we're using GWT, where the HTML is (mostly?) auto-generated — to style something (say, a control), you can either use CSS in a separate file or do it directly in the source code (which you then can't override in the CSS).

@jonathanabbett: Clickframes sounds interesting — I'll check it out.

Thanks again to EVERYONE who replied. Much appreciated!

Cheers,

Martin Polley
Technical writer, interaction designer
+972 52 3864280
Twitter: martinpolley
http://capcloud.com/

On Tue, Aug 25, 2009 at 1:39 AM, Jim Drew cfmdesigns at earthlink.net wrote:

You build in a QA team which is connected to both Dev and Design,

...

On 25 Aug 2009, at 15:53, Jonathan Abbett wrote:
[snip]
But that fundamental designer-developer chasm remains [snip]

When I see a chasm - I like to start building a bridge :-)

Adrian
-- http://quietstars.com

On 25 Aug 2009, at 10:34, Audrey wrote:

I am glad that Jim brought up the QA team. They should have specs, scenarios or prototypes from which to build test plans. If eng knows they'll get a bug filed against them, they're more likely to implement to spec. [snip] Two other really useful groups to get involved are: 1) Customer Support - they had to with angry phone calls from the stuff that crept out in the last release 2) Technical Authors - they had to explain the complicated steps to perform what should have been a simple task in the last release [trim]

Jim wrote:

1. Cultivate a UX test savvy QA person. They can see the 13 shades of gray and single pixel alignment issues at 10 paces. Let them do that consistency checking, and support them in getting things resolved.

Absolutely. But first make sure all 13 shades of gray are necessary and intentional (in my recent example, they weren't). Otherwise it looks either lazy or like the designer doesn't give a damn how much time it will take anyone else, or both.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=44968

Seems this discussion was fruitful, but reading everyone else's posts, I thought of the one thing that slips through the most UX-savvy design, development and QA team: If the lead designer doesn't communicate the exceptions, everyone tries to reverse good UX work.

For example, in a particular link-heavy web design, the lead designer might choose not to underline links. User research may have led him to this decision, even tho it may contradict what basic UX principles would otherwise dictate.

If the designer doesn't communicate this exception with everyone on the team, then all of the UX-aware developers and QA folks are going to try to reverse it every step of the way.

At best, the above results in lots of duplicate "I meant to do that, and yes, the research justifies it" emails. At worst, it can lead to users thinking no one listens to them.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=44968

As most of you pointed out, working closely with developers is probably the best way to ensure your design is well understood and implemented. But it is also a good way to understand what wthe technical problems are and it's perfect to solve them faster, without meetings or email ( I am referring to those little obstacles devs find during the implementation of your requirements. By the way, I usually go downstairs at least once a day and it works for me. Being a IxDesigner is also about relationships and understanding who are you working with and how to deal with that person rather than the other one (also in terms of how asking things)...

Posted from ixda.org (via iPhone)
http://www.ixda.org/discuss?post=44968