This is our process, need your input

17 Sep 2009 - 5:14pm
6 years ago
6 replies
1391 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 - 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