What is your design workflow?

8 Jul 2009 - 9:51am
5 years ago
6 replies
1110 reads
Brian Mila
2009

I'm having trouble with our design process. It seems like it isn't
working, we are falling behind schedule. What I'd like to know
briefly is:

What is your design workflow? Do you do low-res mockups first, or
start with an existing design? (This is in the context of creating a
new application to fit into an existing suite of apps, so the visual
style is already set)

How long does your design process take? If you had to do say a dozen
screens, would you expect going from nothing to handing it to a
developer to take 2 weeks? 4 weeks?

How many iterations do you do on a low-res mockup before you move to
high-res mockup?

How quickly do you iterate on a single screen? A couple times a day,
a week?

Who is at your design review meetings? Product mgr? Project mgr?
Exec. Sponsor? Are they at every design review, or do you work until
you feel the design is "ready" before you present it?

I apologize for the survey-like questions, but I really need to get a
feel for what works so I can make salient suggestions for improvement
around here. If it helps, this is all in the context of a supposedly
agile environment, but the reality is they don't do small iterations,
they do huge chunks and then mark them as "finished".

Thanks,
Brian

Comments

8 Jul 2009 - 10:29am
Sarah Kampman
2008

It's hard to give specifics, because every project is different, but
here are some of the common elements to my design process.

I typically try to work with ONE stakeholder during the early stages of
the design. It's much faster to iterate with a single person, and it
helps reduce unrelated politics. However, you need to make sure that the
stakeholder you're working with is knowledgeable, connected, and
respected. The first allows your resource to act like a proxy SME; the
second ensures that they can connect you with the real users/SMEs as
needed; the third helps the other stakeholders feel comfortable that
someone they trust has vetted the design.

I always start with lo-res mockups, even with existing designs, because
they are so fast to create and change. This also allows the stakeholder
to pull up a pencil and do some direct editing, which saves much time
and miscommunication. It's not uncommon for me to create three competing
paper mockups, eliminate one immediately, and iterate one the other two
designs 3-10 times before moving into a high-res stage. When we're in a
rush, this can take as little as a few days. Again, working with a
single stakeholder is what makes this so speedy. All but one design has
often fallen by the wayside at this point, though sometimes alternative
elements are preserved until we get to usability testing. Occasionally
I'll do usability testing at this stage, especially if there are major
areas of uncertainty -- however, as almost none of our end-users are
local, I usually have to wait until I have an electronic version.

My high-res stage is DHTML, because in our software we've usually got
moving parts (added rows, modal windows, specialized menus) and they're
impossible to really evaluate until you see them in action. This also
allows me to run useful usability testing remotely, and I'll usually
also run some tests internally as a means of illustrating where the
design is and soliciting constructive feedback. The DHTML prototypes are
usually in a halfway state between wireframe and "decorated." I've got
an existing HTML template with some realistic images and colors that I
use, and I'll also fill in whatever styling is important to the task,
but I do not spend hours on icons or the styling specifics. Creating the
prototype typically takes a few more days, depending on how complex it
needs to be. iQuery has been a *huge* time-saver here, as has building
up a set of templates for common page types.

Somewhere around this stage is when I start shopping the design out to
other people who need to approve it. The advantage of this is that the
major kinks have been worked out and I often have some usability test
results to validate that the design is serving its purpose. There are
often a few open issues that I'll get feedback on, but very few
back-to-the-drawing-board problems. These approval meetings are usually
with only one or two people at a time, because I've found that I get
better feedback that way.

You mention that you're working in a (semi-)agile environment. I have
been working on agile teams for about 5 years now, and in my experience,
design has to happen at least one iteration before development. The only
exception to this is when creating pages that are 90% similar to others
in the system (e.g., creating a new form, when you already have a form
template).

I'm happy to talk more about this offline; ping me if you want to
continue the discussion.

Regards,
Sarah Kampman

8 Jul 2009 - 10:36am
Sarah Kampman
2008

Correction: iQuery >> jQuery

-----Original Message-----
Creating the prototype typically takes a few more days, depending on how
complex it needs to be. iQuery has been a *huge* time-saver here, as has
building up a set of templates for common page types.

8 Jul 2009 - 12:28pm
Brian Mila
2009

Sarah,

Do you find your requirements change at all during this process?
I'm having issues where the prototypes are revealing things that are
missed, which is good. But the business requirements have already
been set before the design process starts, so now the requirements
start to change. It spirals down from there and pretty soon the
development is beginning and the design is still changing.

I think the solution is to have design involved sooner in the
process, in the business requirements phase, but I want to have some
advice to back up this suggestion. Another option could be to give
more time to design, which currently we are getting 2-4 weeks.

Thanks,
Brian

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

8 Jul 2009 - 7:53pm
Sascha Brossmann
2008

Brian,

you might have already hinted yourself at an IMHO highly possible
source of your troubles by labeling your process as 'supposedly agile'
etc. Apart from the regular potential pitfalls of agile processes[1]:
an 'agile' process that isn't will consequently in most cases inherit
the type of problems that agility is supposed to solve. If your
management is currently not sufficiently committed to get this fixed,
you are trying to tune the wrong set of screws when just looking at
the design process: The real problem could quite well be sitting one
stage above... (and needs to be dealt with _there_).

> What is your design workflow? Do you do low-res mockups first, or
> start with an existing design?

Personally, I am most often concerned more with concept/product
development/ideation/etc. Hence starting with an existing design is
rarely an option at this stage. Sorry, if I might not be too helpful
here.

> (This is in the context of creating a
> new application to fit into an existing suite of apps, so the visual
> style is already set)

Erm... visual style ≠ design ;-) But how about already established (and
well working!) behavioural patterns, affordances (ok, those are often
visual), ...?

> How long does your design process take?

Always different. Highly depends on budget, deadlines, priorities,
people(!), ...

> Are they at every design review, or do you work until
> you feel the design is "ready" before you present it?

Depends on the ability of the stakeholder to deal with the low-res
stage, i.e. imaginative skills, design process savvyness, etc. Some
worst case people just don't get it until you have already a quite
refined prototype (and then get stuck on discussing really minor
details instead of stuff that matters *sigh*). This type is often hard
to deal with (at least for me). The more grateful types are much
better able to cope with iteratively exploring a possibility space,
and may provide good feedback already at less ready/refined stages.
And in case of a stakeholder that is imaginative, understanding, and
committed, showing and discussing things as early and often as
possible IMHO really pays and may evolve into a heavily inspiring and
rewarding mental ping-pong incl. according results. At least for the
more stimulation-seeking types amongst us. :-) YMMV - there are enough
people who prefer to work a little bit more secluded until they feel
safe to present something more 'ready' (and do better this way).

> Do you find your requirements change at all during this process?

Yes, of course. Though in agile, requirements should actually never
change *within* an iteration, only *between* iterations. In other
words: design work normally feeds the backlog (or an respective
equivalent). If management is not able to restrain the urge to
withhold new requirements until the next iteration, the whole process
starts to go awry. Which can get quite costly in terms of momentum,
time, motivation, quality, ... (and money).

(Mind you, I don't hold the opinion that agility is an all-or-nothing
type of game. IMHO it is quite possible to have just _some_ agile
components and do well with them. Provided: sufficient awareness of
the respective whats and _whys_.)

> I think the solution is to have design involved sooner in the
> process, in the business requirements phase,

AB. SO. LUTE. LY. (Though this probably will still not solve the
problems your organisation might have with somehow
half-baked/half-minded agility.)

HTH.

Cheers,

Sascha
--
[1] In my experience design in an agile environment should i.e. strive
to be at least one step/sprint/... ahead of development and be able to
provide not only screens but, much more important, a sturdy, flexible
conceptual/behavioural/visual framework. [see Sahra's comment above,
taking the same line]

8 Jul 2009 - 12:41pm
Anonymous

Speaking to just one point....

Unless you are the developer, or familiar with the software or
framework behind the functionality, I would not recommend doing the
whole design and then passing it to a developer, unless cost and
performance are not issues. The biggest mistake I see clients make is
trying to separate design from development, as if they were not two
sides of the same coin.

As a company that does both design and development, and frequently
one or the other, for websites, it is always most difficult when we
are handed a design created by someone who does not know the
framework upon which the site is being built. (It's especially bad
when the designer really doesn't know interface design.) This
frequently ends up resulting in additional costs to the client.

Even more ideal is to incorporate design into the iterative
development process, so design and development are dovetailing and
weaving together. The pre-development (iteration 0) work can then
limit focus to the overall design framework, what kinds of design
patterns to work with, color palette, leaving the specifics for when
the development is happening, when design can adapt to actual
functionality and workflow needs as apparent when looking at the
actual result, rather than via speculation via mockups.

Of course, Agile is not for everyone. In general, though, one part of
Agile I think is critical throughout any project: regular
communication. Lots of little iterations rather than a few big ones.
The Big Design Up Front (and don't talk to me until I say it's
ready) approach has less appeal to me in this rapidly evolving and
ever interactive world we work in.

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

10 Jul 2009 - 7:47am
Brian Mila
2009

Thanks for all the comments and suggestions. I have a meeting next
week with the stakeholders of this project, I will suggest that we
work on changing the design process to be included earlier. It
might be too late to truly benefit this current project, but may be
helpful for the next project. I also will be scheduling a meeting
with the development leads to discuss ways to improve our "Agile"
process.

Brian

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

Syndicate content Get the feed