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