This is our process, need your input

17 Sep 2009 - 5:14pm
4 years ago
6 replies
910 reads
Jonathon Juvenal
2009

This has been on my mind a lot lately. I feel like our process is
very fast and accomplishes the right things, but I don't have much
to compare it to. It'd really mean a lot to me to know your
company's design process and to gather any feedback you have on the
process I outline below. I'm looking for ways to improve what we
do.

So here's how we do design at onegreatfamily.com:

We are a small company, we have 8 developers. We consider ourselves
an "Agile/Scrum" shop. We have 2 designers, one assigned to the
windows app and one assigned to the website. The designer has 10
business days to do the following:

1. Gather requirements from the CEO and VP of marketing. Typically
those two have provided the designer a one sentence "task" they
want to accomplish. So the designer queries them for the initial
details.

2. Based on the size of the requirements gathered, decide how much
they are going to be able to do in the 10 days they have to design.

3. Talk to lead developers if there are any uncertain technical
issues that the designer anticipates.

4. Quickly draw up wireframes of the primary flows in whatever
fidelity is important based on the requirements.

5. Present the initial wireframes to the CEO and VP to discuss and
gather feedback.

6. Make changes to the wireframes based on the feedback.

7. Conduct user labs on what is drawn up so far either with internal
non-project people (like customer support) or by bringing in our
target customers. Sessions are usually 45 minutes and done with
paper prototypes. 2-3 people are brought in.

8. Makes changes and/or discusses issues with CEO and VP.

9. Add all visual design details if not already present.

10. Write 50-80% of what we call our "user stories" which is our
streamlined design document.

11. Query and discuss with lead developers on any technical
concerns.

12. Do a follow up user lab if needed.

13. Present progress to CEO and VP, gather feedback.

14. Make changes based on the feedback.

15. Present one last time to the CEO and VP for an official "final
sign off". Typically by this stage the CEO and VP have reached a
consensus about the design and have very little left to change or
discuss.

16. Show the final state of the design and the design doc to the
developers for their design input and a last "can it be done"
approval/review.

17. Discuss feedback with CEO and VP if necessary.

18. Make changes based on the developer's feedback.

19. Officially hand off the finished document including supporting
screenshots and the Illustrator files that contain all the finished
graphic design to the developers and QA.

20. The developers then code the html and the functionality according
to spec.

21. QA then uses the design doc to test against what development
gives them.

Comments

18 Sep 2009 - 7:46am
ELISABETH HUBERT
2007

Some things that stand out to me and I apologize if they are out of
order.

First, I'm curious if the CEO and VP get their requirements from the
user. Meaning is anyone ask the user what updates they need to
complete their tasks. As you know it's usually a balance between
user and business needs. I'm wondering if your team is planning on
being a strategic partner to the CEO and VP one day or if there is
another team that is doing so already, or maybe your team is already
doing so.

Second, Do you create the user stories before you wireframe? It would
seem like that would be the best way to ensure you are thinking about
the different user types and use cases that need to be considered for
the design. Maybe user story is another word for detailed use cases?

Third, before wireframing and while you are querying the execs, you
may want to be thinking about other user testing that you've done
and how that may peak some insight into your new solution.

Why does the designer only have 10 days for their work? Is this due
to agile scheduling? When I worked in an agile environment what
helped us was taking the time up front to have an overarching user
strategy and then inserting bits of that into each iteration. Because
we already had a user focus we were able to easily adapt any new tasks
into our schedule because we could quickly, if applicable, fit them
into the strategy. This took a lot of the what if thinking (concept,
strategic, what if thinking not creative design what if thinking) out
of the wireframe process then the designer could focus only on the
task.

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

18 Sep 2009 - 8:38am
Anonymous

Lets pull out the key words here and see where you have them.
You have the word "design" in step #2.
The first time I see the word code is in step #20.
50-80% of user stories are written in step 10. This should be step 1
and should be done by the product owners(CEO/VP). You should be
voting on how big the user stories are. S,M,L,XL,XXXL and if it is a
XXXL it goes back to the product owners to be split up into multiple
user stories. I can go on and on about how Scrum works.

You have a semi-scrum hybrid type thing going on but in the end your
working with a waterfall methodology here. I know people are going to
argue this with me but in the end it is true. This is not Agile/Scrum
but if it is working then don't look to change just because
Agile/Scrum is the new buzz. If it works it works. Good job and keep
going. :)

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

18 Sep 2009 - 10:11am
Anonymous

Generally, it is great that you're thinking through this...that means people
are committed to UX.
I'll list some areas of consideration (may not be problems but might be
opportunities yet)

1) Are designers able to do do user research? (outside of usability
testing, in a raw setting).
It is amazing how this will give them empathy for what people really are
doing, what motivates them..their goals...attitudes to technology. Empathy
for a designer is a motivating force to cut through the chase of features
and requirements, to give people what they want. Without this insight and
strength, the designer is often trying to cram stuff in, taking it on faith
from a product owner what people want. Having real user research at hand
designers can make calls like "you know what, I know we wanted this feature
but based on user X and user Y ... I feel we're not going to be able to
deliver it to them in this way...instead though, I think we can make them
really happy with this alternative." If a designer - who's responsible for
meeting user needs - isn't challenging the organization's beliefs about what
it needs to do and what people want then something is probably wrong with
that designer. That's what they are paying for!

2) In most dev shops, a really novel interaction can stump dev and thereby
challenge the design because it can't be achieved.
The best way to avoid is to get that stuff solved in an iterative phase
(call it agile if you want, but its not the same as big A Agile), where
design and select devs work together. Then when you've proven it can be
done you wrap up all the specs and the architecture -- and move into
production. This is strongly advocated by Alan Cooper
here<http://www.cooper.com/journal/agile2008/>.
Don't swallow Agile whole. What is it going to give you? I think the
little "agile phase" perspective is the enlightened perspective and will
take root because it best aligns with the underlying needs of the business,
the designers, and the developers. Look into it at least.

3) Designers should be involved while dev is ongoing (before testing) to
make sure things are going in the right direction. Very big and obvious
things can change when dev starts cranking, and you need designers to be
right there lockstep. Devs love this because they want to make sure things
are right, and want to discuss roadblocks/alternatives. You will have big
problems if you treat this as purely a QA function, because developers hate
reworking something. I remember working 1:1 with devs when they started
coding and being amazed by the number of things that I thought were obvious
in my spec, but devs never even noticed. If we missed those things early
the ship would gone quite a way off course - and we'd have to rejig our
ultimate destination. Devs aren't as attuned to interaction design and
visual design stuff - no surprise it is not their job to be!

Any org that does the above 3 things is a couple of standard deviations
above the norm, and guaranteed to be successful imho. Anyone who can
operationally make the above 3 things happen in an organization, will never
be out of work - there is infinite nascent demand for this.

Navid

On Thu, Sep 17, 2009 at 10:14 AM, Jonathon Juvenal <jjuvenal at yahoo.com>wrote:

> This has been on my mind a lot lately. I feel like our process is
> very fast and accomplishes the right things, but I don't have much
> to compare it to. It'd really mean a lot to me to know your
> company's design process and to gather any feedback you have on the
> process I outline below. I'm looking for ways to improve what we
> do.
>
> So here's how we do design at onegreatfamily.com:
>
> We are a small company, we have 8 developers. We consider ourselves
> an "Agile/Scrum" shop. We have 2 designers, one assigned to the
> windows app and one assigned to the website. The designer has 10
> business days to do the following:
>
> 1. Gather requirements from the CEO and VP of marketing. Typically
> those two have provided the designer a one sentence "task" they
> want to accomplish. So the designer queries them for the initial
> details.
>
> 2. Based on the size of the requirements gathered, decide how much
> they are going to be able to do in the 10 days they have to design.
>
> 3. Talk to lead developers if there are any uncertain technical
> issues that the designer anticipates.
>
> 4. Quickly draw up wireframes of the primary flows in whatever
> fidelity is important based on the requirements.
>
> 5. Present the initial wireframes to the CEO and VP to discuss and
> gather feedback.
>
> 6. Make changes to the wireframes based on the feedback.
>
> 7. Conduct user labs on what is drawn up so far either with internal
> non-project people (like customer support) or by bringing in our
> target customers. Sessions are usually 45 minutes and done with
> paper prototypes. 2-3 people are brought in.
>
> 8. Makes changes and/or discusses issues with CEO and VP.
>
> 9. Add all visual design details if not already present.
>
> 10. Write 50-80% of what we call our "user stories" which is our
> streamlined design document.
>
> 11. Query and discuss with lead developers on any technical
> concerns.
>
> 12. Do a follow up user lab if needed.
>
> 13. Present progress to CEO and VP, gather feedback.
>
> 14. Make changes based on the feedback.
>
> 15. Present one last time to the CEO and VP for an official "final
> sign off". Typically by this stage the CEO and VP have reached a
> consensus about the design and have very little left to change or
> discuss.
>
> 16. Show the final state of the design and the design doc to the
> developers for their design input and a last "can it be done"
> approval/review.
>
> 17. Discuss feedback with CEO and VP if necessary.
>
> 18. Make changes based on the developer's feedback.
>
> 19. Officially hand off the finished document including supporting
> screenshots and the Illustrator files that contain all the finished
> graphic design to the developers and QA.
>
> 20. The developers then code the html and the functionality according
> to spec.
>
> 21. QA then uses the design doc to test against what development
> gives them.
>
> ________________________________________________________________
> 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
>

18 Sep 2009 - 1:00pm
Anonymous

Navid,

Great response. You hit the nail on the head. That was very well put
and sounds like a real fun agile scenario. I mean the whole point of
the process in my opinion is really for everyone to get a chance to
have some ownership and put there expertise into the product from the
beginning and you have that example in number 1. You also have that
example with the designers and developers working side by side in 2
and 3. That is the point in my opinion. Everyone has a different
background and expertise but when you bring those differences into
one group and say now everyone has an equal part and we all have to
listen to what everyone has to say from the beginning. Well then I
find we learn that not much becomes impossible and you tend to not
hear things like "I can't do that", It turns into "How are we
going to do that together as a team" which makes it actually fun.

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

18 Sep 2009 - 2:38pm
Eirik Midttun
2009

#1-19 looks an awful lot like Big Design Up Front
(http://en.wikipedia.org/wiki/Big_Design_Up_Front) and that is
definitly not Agile. Just adding to the points already made by Brian
and Navid.

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

20 Sep 2009 - 9:13am
rajunov
2009

My quandary is that you mention "developers" in #3 and #16/18, and
it seems the developers' input is more of a "let me know if we are
doing something impossible, otherwise we'll just go along" type of
feedback, and the coding starts after the design is finalized.

Developers can't always predict the technical issues that will come
up, or whether something doesn't make sense. One way I've seen it
done is to have the developers coding as soon as the wireframes are
out; thus the programming follows an iterative process concurrently
with the design. Any changes that are dependent upon each other will
most likely surface at the same stage.

And yes, I agree with Brian, your user stories should be done first,
and should be based on research.

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

Syndicate content Get the feed