 |
« | Week of Jan 25 | < | Individual Entries | > | Week of Feb 8 | » |  |
 |
 |
Camera Studies
design, processes & methodologies
February 05, 2004, 11:15 PM
Sonia Wendorf, the resident industrial designer on our capstone project team, has introduced us to the concept of "camera studies" and is currently designing one for our own data collection purposes.
A camera study is a user research technique where the research team gives participants in the target user group disposable cameras and asks them to photograph important events, objects, and places they encounter during their day, as well as possibly writing down quick notes describing what they're doing and why they took that particular photograph. Alternately, the researchers may just ask the participants to take one photograph about every hour to collect more time-based data. The researchers then develop the film and review the pictures to gain an understanding of what goes on during an average day in the life of their users. If necessary, they may do an artifact walkthrough with the users after viewing the photographs to gain a more in-depth understanding.
The purpose of the study is to gain a visual understanding of the user's activities and habits during their average day so that the design team can get a sense of their lifestyle. And because the researcher need not actually accompany the users during the data collection process, this technique can glean information from a broader range of users than, say, ethnographic observations can. One could see the results of such an inquiry feeding quite nicely into a set of realistic personas for a project.
The advantage of this approach is that it helps the design team see the world through the participant's eyes rather than just their own; the participant is filtering the information by choosing what to photograph. Furthermore, since the technique allows for running many users in parallel, the design team can get data on many more users which allows for richer data with greater variety. The downside is that the data collected won't be as richly detailed as the data an experienced ethnographer could collect during an extended observation session. So although the technique may be quite helpful for getting an overall impression of a participant's lifestyle, it's less useful for, say, understanding how that participant fits into the larger corporate organization or how the software they use impacts their job performance.
Anyway, it's an interesting technique to add to the toolbox. As an aside, Dan has a post up on a few more from Maya Design.
Divvying Up Research
design, usability
February 04, 2004, 11:07 PM
We've started our exploratory user and problem domain research phase for our capstone project. One of the hard things about managing a sizable research project is figuring out how to divide up the labor; research (and design) doesn't lend itself well to task division since all design team members really need to have an understanding of all research conducted so that they can develop appropriate design solutions. Yet if the entire team must be involved in all research activities, then this 1) introduces serious coordination overhead and 2) limits the amount of research the team can conduct since so little can occur in parallel. What to do?
The approach we are taking is to divide up the overall research task into five areas we consider important and assigning leadership of each area to a particular team member. The five areas are:
- Goals and attitudes of the teachers
- Goals and attitudes of the students
- Advantages and limitations of existing competing products
- Fitting the product into the user's lifestyle
- Fitting the product into the classroom process
This approach seems to be working reasonably well so far in that every team member seems clear on what his or her responsibilities are and has been able to pick up the task, break it down into action items, and run with it. However, we don't want the group to get too divided; there's a risk that we'll all just go our separate ways without any clear idea of how these subtasks are fitting into the larger goal of understanding the design problem so that we can develop effective solutions. To mitigate this risk, we're going to try overlapping our tasks so that we can all participate in many activities and make a point of reviewing our findings in our meetings.
A second risk during the research phase lies in doing lots of research without knowing what you're getting out of it, then finding at the end that the questions you asked weren't relevant to your design problem whereas there were many questions you needed answers to that you never asked. To avoid research that goes nowhere, we're aiming to ensure that all research activities fit into a set of documents to guide our design:
- A list of personas from our two target user groups (teachers and students)
- A set of visionary scenarios describing how our product will be used
- A list of tasks that the interface must support (the user-centered equivalent of a software engineering functional specification)
We also plan to begin active design ideation after only about three weeks of "pure" research activities. Hopefully, this will help us avoid following research directions that are not actively informing our design.
Email Rob:
Kberger @ Macromedia
people
February 02, 2004, 09:29 AM
Congratulations to Kenneth, who left today for sunny San Francisco to work for Macromedia. He'll be working on making Dreamweaver better, which is a worthy goal since it sure does need improvement. We're all going to miss him, but his skills are well placed. Good luck to him in this and all his future endeavors.
And San Francisco had better watch out...
Email Rob:
The Aims of Rob, a Mortal
personal
February 01, 2004, 01:18 AM
This entry is private. Forgot the password? Ask the Keymaster!
Email Rob:
Email Rob: