I've done this twice. Once to redesign a CRM system for a technical support group and another time to design a content management application for technical writers. Each time I basically joined the group for some time, taking support calls or writing technical bulletins under the guidance of the group's manager. I went to staff meetings and got good advice from my coworkers. After I walked the walk for a while, I had a much better understanding of what was important or not.
Both groups were very accepting of me and both projects were successful and well-received. In subsequent design projects I've tried to get similar experience, but the domains generally didn't permit this. I'm also a big fan of participatory design, where one or two real live users are on the design team - that's worked well in projects too. Michael Micheletti On Wed, Jan 21, 2009 at 2:55 PM, Julez <huj...@gmail.com> wrote: > Hi, > > Does anyone out there have the experience of actually performing a given > job > (for at least a day or three, perhaps longer) as a means of really > researching context, tasks etc.? Specifically, I am thinking of an > enterprise context, where the user doesn't have choice in tools, workflow > and there are some highly developed skills (ie more than the basic web > skills of an e-commerce user). Also, I am contrasting this approach to > on-site observation, empathic modeling and user role playing. > > For example, working in a call center as a first line telephone customer > care agent. Sitting down with call center agent, getting some basic > training and having that person watch your back to prevent major > catastrophes, You answer calls, use the system(s) to retrieve and enter > information etc., essentially it is you performing the job. > > This was something I though of proposing ages ago when I wanted to analyze > and model the work of a particular type of system analyst. It never came to > fruition (due mainly to technical skills gap, but also legal issues with > outsider using systems) and I ended up doing standard contextual > observations. It was great for insight into high-level aspects of the > product and job that had issues (most of which we were already aware of) > but > not much nuance. > > It is inspired by a story I heard (circa 2001?) about a financial analyst > getting a job at an Amazon.com warehouse as a means of gauging their > likelihood of hitting/exceeding their numbers. > > There are a myriad of reasons not to do this, namely resource/time > constraints, but I am curious to see if other IxDers, particularly those > with a research bent have experience with this and could provide some input > on how it compares to CI. Of course input from people with no experience > is also welcome. > > What context was this performed in? (Real vs. Realistic Simulation) > > Did you have some basic, prior understanding of the domain? > > Did you do training? > > What did you call it? (methodology) > > Was it disruptive to work setting? > > Does it provide a level of insight worth the time/hassle of setting it up? > > > Cheers, > Julian > ________________________________________________________________ > Welcome to the Interaction Design Association (IxDA)! > To post to this list ....... disc...@ixda.org > 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 ....... disc...@ixda.org Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
