How do you make sure your design gets implemented right?

24 Aug 2009 - 4:13am
4 years ago
16 replies
1219 reads
martinpolley
2007

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/>

Comments

24 Aug 2009 - 5:00am
martinpolley
2007

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/

24 Aug 2009 - 5:29am
Adrian Howard
2005

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)?

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 - twitter.com/adrianh - delicious.com/adrianh

24 Aug 2009 - 5:41am
Anonymous

Coming from the development side of things myself, I've always found
it crucial to have a close relationship with the developers. This
includes letting them participate in some of the discussions and
design sessions early on. This lets them feel like they have more of a
stake in the end product than simply being the machine that stamps out
the widget you designed. They were part of the design, they've heard
you talk about it, they've talked about it, perhaps they even through
in an idea or two. This is in addition of course to all of the stuff
you mentioned.

Another thing this ensures is that you haven't requested a
functionality that is beyond the scope of the current development time-
frame, or the technology you're currently using. Developers sometimes
look at something and say - "Well, I can spend 2 hours building this
with an existing control or build it as designed and it'll take 12
hours. Maybe they won't really notice or care..." If they were part of
the design discussions early on, the functionality won't be a
surprise, and it's specific qualities/nuances will have been built
into the schedule before it was even handed off to them.

Also - by having a close, friendly relationship with them, they're a
bit less likely to do whatever the heck they want just 'cause they
feel like it, because they respect and like you, and by extension,
your designs.

One area where I found this to be happening at one company with Agile/
Scrum was when the dev. team was ahead of the design team. They knew
what widgets needed to be built, and so they were busy hammering out
the widgets before design had even been completed/approved. Then, when
the final designs came along, they implemented them in the easiest
possible way, around the widget and controls they'd already built,
rather than building it from scratch.

This is a somewhat larger problem, in that the whole software
development process is reversed. We had to ask the dev. lead and
project manager to figure out something else to do with developers
instead of trying to work ahead of the design team - it ended up
happening cost us more because they were building each widget twice -
once before design and once after to get it right.

Brandon E. B. Ward
brandonebward at gmail.com
UI • UX • Ix Design
Flex • Flash Development
Portfolio: http://www.uxd.me
LinkedIn: http://www.linkedin.com/in/brandonebward
VisualCV: http://www.visualcv.com/brandonebward

A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects.
- Robert A. Heinlein

24 Aug 2009 - 5:44am
Janne Kaasalainen
2008

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

24 Aug 2009 - 5:39pm
cfmdesigns
2004

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 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/>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

24 Aug 2009 - 7:59am
Charlie Robbins
2009

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).
>
> 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/>
>
>
> ________________________________________________________________
> Reply to this thread at ixda.org
> http://www.ixda.org/discuss?post=44968
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

25 Aug 2009 - 9:08am
bminihan
2007

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

25 Aug 2009 - 9:53am
jabbett
2008

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 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
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

25 Aug 2009 - 12:34pm
Audrey Crane
2009

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

25 Aug 2009 - 11:23pm
cfmdesigns
2004

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.

26 Aug 2009 - 10:16am
martinpolley
2007

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,

...

26 Aug 2009 - 10:32am
Adrian Howard
2005

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 - twitter.com/adrianh - delicious.com/adrianh

26 Aug 2009 - 10:42am
Adrian Howard
2005

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

I find both groups give a fascinating perspective and often spot
issues that I've missed.

[snip]
> 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
[snip]

To be fair - I don't think that this sort of problem is always caused
by a lack of respect. I think many designers find it difficult,
especially when they're under a lot of time pressure, to remember that
it's not obvious to everybody that some changes are significant and
others are not.

Cheers,

Adrian
--
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh

26 Aug 2009 - 3:29pm
Audrey Crane
2009

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

26 Aug 2009 - 7:23pm
bminihan
2007

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

27 Aug 2009 - 2:04am
Pietro Desiato
2008

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

Syndicate content Get the feed