Hi Jonathan, I recommend you make a menu of services, and that you have a simple-medium-advanced version of each service. Your skill and flexibility will guide you in setting the scope for each project.
The menu of services: Showcasing your work in a one-page document gives your teammates the predictability they need as they learn the value you provide. I have been the main UX guy in a formal PMI-certified team, and one of many UX people in a more laissez-faire environment. In each case, the problem before me was deciding on, recommending, and justifying specific exercises. I realized over time that presenting a clean, one-page overview of what I offer is a powerful and simple tool. Most importantly, it makes my work more predictable and familiar to my users/teammates. I noticed that after a few meetings when I'd bring the menu that they would start referencing it. They were learning my system with very little effort. Soon, they got good at figuring out what I'd propose for a type of project. The alternative I see is that some people try to *explain* UX methods to their team. That's like trying to explain an interface to the user before they can use it. You notice they don't want your dogma - they want your help, and they want it now. So, giving them something short, predictable, regular menu made it much faster and easier. In case one page seems too simplified, I'll admit there are more pages that unpack from the first one. For example, I have a full checklist for usability testing that includes "refresh browser(s), clear history, and restart if necessary to prepare for the next user". The level of detail behind the scenes is up to you. The graduated simple-medium-advanced version of each method in the menu: Each project demands a unique blend of work that you can prepare for. I'll use personas as an example. For instance, if I have to turn around a new site in a couple of weeks and have no time/budget for user interviews, then I'll write ad hoc profiles that are the "simple" version. If I have a full redesign with big budget and more than a year's time, then I'll do exploratory testing to figure out user goals and mind-sets, which might be the medium version. If we can go out and interview users before anything else and define comprehensive personas for a product/site, then that's the advanced version. In many ways, this gradation of work types is most valuable to me/the UX team. It's like the recipes behind my menu of services. But, it's a great way to show the team how you're tailoring your work from one project to another. When they see that from you, they start to see how flexible you are and it leaves the impression that you're really listening and thinking on your feet. Plus, it's good for the budget to be able to tailor your work. The notepad version of my process: I use scenario-based design. (It's not trademarked, so I can sleep at night after doing it.) Scenario-based design: > determine user goals + business goals >> write scenarios (how users accomplish those goals; success and failure criteria) >>> outline/define features + requirements, prioritized by business and/or user goal >>>> iterative design + testing I hope this helps. - Jay On Fri, Apr 4, 2008 at 2:39 PM, Abbett, Jonathan < [EMAIL PROTECTED]> wrote: > I work in a small open-source software development team within a medical > informatics research group. Until last year, our development > methodologies had been haphazard -- there were only two or three of us > working in the same room, and we were devising our software's > requirements as needed. Now we have a substantial relationship with a > corporate partner, the group is growing rapidly, and we're implementing > more formal development workflows, lifecycles, and conventions. > > As the "UI guy," I've taken it upon myself to devise a User Experience > Design Process. Ideally, it will identify how the UX "team" will work > together with project management, the engineering team, and external > stakeholders, and describe what tools/deliverables will be used > (personas, user stories, use cases, mockups, wireframes, etc.). > > The materials I've found about "process" have been very heavy, seemingly > from corporate environments, so I'm curious if anyone out there, > particularly those in small/medium-sized groups or teams using Agile > methodology, can share their design lifecycles. > > Thanks, > Jonathan > > > > ______________________________________________________________________ > Jonathan Abbett [EMAIL PROTECTED] > IndivoHealth PCHR Children's Hospital Informatics Program > http://www.indivohealth.org/ http://www.chip.org > > ________________________________________________________________ > 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 > -- Jay A. Morgan Information Architect. Business man. ________________________________________________________________ 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
