Design, Develop, Create

Showing posts with label IDEO. Show all posts
Showing posts with label IDEO. Show all posts

Wednesday, 16 October 2024

Product (inc. Service) Design Resources

The Service Design Tools site is a wonderfully detailed collection of resources suited to evaluating user contexts, for helping you adopt a `design attitude'. The resource is supported by an on-going project aimed at bridging education, academic research and professional practices.

The design methods finder offers another possible source of inspiration for identifying research (and design) methods to apply to your own design research project.

The Nielsen Norman Group (Jakob Nielsen, Donald A. Norman, Bruce "Tog" Tognazzini) has been behind a sustained drive to professionalise high tech design by defining a new kind of occupation; Interaction Design.

https://useit.com
This is (was) Jakob Nielsen's site for sharing thoughts on the principles of interaction design, events and ID community material.

Bruce Tognazzini's site and his take on design principles.

Monday, 20 January 2020

(51) IDEO Method Cards

A product design research methods compendium

These methods are organised into four families representing the emphasis in how each method may be applied. However, there is no reason why you shouldn't consider a method applicable to one of the other categories. These methods simply represent ways to inspire us to consider different ``ways to empathize with people'' to seek insights, understand behaviour, perceptions, needs, goals [IDEO, 2003]. All these methods and categories emphasise the empirical world as the source of ideas and inspirations. The empirical world encompassing social and material structure, attending empirical moments and events as nexuses of action, historical and scientific context, the happening of things of both great and small significance (global and local).

The idea underlying `Learn' is that hard data, measurements, statements of the facts as they may be known. Observations and data gathered from empirical settings, treating the world as a kind of living lab. This sort of data tends to be treated as more objective, scientific, and provides the material for more statistical and quantitative analyses. It offers the potential for revealing unexpected patterns and insights that demand the use of other methods to understand further. `Learn' methods help us build the data and evidence addressing focused research questions, to follow up hunches and ideas that may be tested or evidenced by measurement data (rather than data mining as such).

The `Look' category implies that people going about their lives and happenings in the world are our best teachers. These are methods for gathering insights from interpretive observations, shadowing and participating in `the wild' [Buxton, 2007]. These methods emphasise the value of the empirical world in the language and terms of its use by its participants. The data gathered depict social realities, actual happenings and incidents; evidence of real people with biographies coping in actual settings, surrounded and constituted in the (seemingly) ephemeral and trivial real-world of people. `Look methods' enable generalised undirected problem identification, the broad assessment of an area before narrowing down on a specific concern.

`Ask' methods seek people's direct participation in constructing research data. People aren't `social dopes', they understand their own conditions. People have points of view and knowledge that they will readily share if you enable them. While this kind of knowledge may be idiosyncratic and bounded the more of it you can gather the more universal may be our understanding overall. `Ask' methods are useful when you have identified a research goal, an application, and a context. They are ways of revealing insider knowledge and practical contingencies that your project will encounter and leverage.

`Try' methods are all kinds of action research, some in-vitro (experimental setting) and some in-vivo (in the wild). These are methods that test how your project may work, how it may change behaviour and understanding, how useful and applicable it is. `Try' methods are active designed interventions and thus quite experimental in character. They encompass controlled simulations, experimental scenarios, to living labs in `the wild'. The focus of these methods is testing. They test feasibility, practicality, understandability. They seek people's active involvement and feedback on the design and application of the project.




(source: the IDEO Method Cards booklet [IDEO, pp. 2-3, 2003])

References

Buxton, B. (2007). Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann, San Francisco.
IDEO (2003). IDEO Method Cards: 51 Ways to Inspire Design. William Stout, Palo Alto, CA.

Wednesday, 31 October 2018

More research methods anyone can use

A pointer to an article by Emily Esposito (at invisionapp.com - link)

source: invisionapp.com 
Emily outlines four research categories: primary, secondary, generative, evaluative.
I feel that these categories map more or less closely across the IDEO categories of: look, ask, learn, try

Friday, 13 April 2018

The Human Centred Design Kit

Reimagining the shopping cart - IDEO's deep dive process filmed for ABC’s late-night news show Nightline (1999), narrated by Ted Koppel (link).

IDEO have put together a little book on design research ethics - do no harm right! (link)
"Respect your participants!
Some methods depend upon other people, often strangers, sharing generously their time, thoughts, and feelings. Have consideration for their health, safety, privacy, and dignity at all times.
Her are some principles that guide IDEO's interactions with participants:

  • approach people with courtesy
  • identify yourself, your intent, and what you are looking for
  • offer to compensate participants
  • describe how you will use this information and why it's valuable
  • get permission to use the information and any photos or video you take
  • keep all the information you gather confidential
  • let people know they can decline to answer questions or stop participating at any time
  • maintain a nonjudgmental, relaxed, and enjoyable atmosphere" (IDEO, 2003)

IDEO.org has also created a set of resources for human-centred design for impact in challenging environments. The Field Guide is a new take on the IDEO design cards which I have used for teaching for a number of years. The examples/cases in the book provide nice illustrations for my students. Go to designkit.org for Design Kit: The Human-Centered Design Toolkit from IDEO for a range of resources and courses - many free.
Books, guides, and free downloads from designkit.org

  • From IDEO itself on the Method cards (link).
  • As a diversion, MethodKit have indexed a large collection of social, entertainment, cultural and business purpose card sets (link)

Monday, 4 September 2017

IDEO - Creative Confidence

Reimagining the Shopping Cart (ideo.com)

In what is now recognised as a seminal inside account of IDEO's design process ABC's Nightline broadcast this documentary video circa 1999. )
Search to view online - inside ideo abc nightline shopping cart - (the full video is around 22' long or posted in 7' parts).

Some key quotes from the video have become canon...
"The only thing that matters in software is the experience of the user"
"It's impossible that the boss is going to be the one who has had the insightful experience!"
"Trying stuff and asking forgiveness instead of asking permission"
"Fail often in order to succeed sooner"

The Kelley brothers of IDEO have also published on their approach
Creative Confidence
"Too often, companies and individuals assume that creativity and innovation are the domain of the “creative types... each and every one of us is creative."
http://www.creativeconfidence.com


Some questions:

  • What is focused chaos?
  • Is this a sane way of working?
  • Is management control necessary? If so why? What forms of control are present here? When is control present? Who controls the process?
  • What problems do you foresee with this kind of organising?
  • If watching this video for the third or fourth time - try to notice the features that didn't belong in typical 1990s workplaces? Features that may be mainstream in today's high-tech workplaces.
  • If you wanted to introduce this style of working into your own organisation: how would you justify it? how would you try to implement it?

Are you interested in what product designers actually do in a shared project workspace? Have a look at this time-lapse video of a week in 2 minutes (link).


Sunday, 6 September 2015

Try (ID research)

We consider techniques and strategies for prototyping and designing for interaction, user centred goal-driven scenarios.

TECHNIQUES FOR DESIGN AND TEST
Interaction designing is predicated on a belief in trial and error, using prototyping and mock-ups to test new design ideas. IDEO’s ‘Try’ cards suggest methods to inform design decisions as the development of a new product progresses. These methods or strategies focus on user input, feedback, and responses as they attempt to use a new technology to achieve some goal. The methods stimulate and simulate users’ experiences, feelings, and perceptions in ways that are quite often completely absent or ignored in traditional product design projects. Among these techniques ‘prototyping’ in all its various guises is particularly valued by both developers and users as they grapple with the challenge of designing interaction between user and technology (Moggridge, 2006).
Table: IDEO ‘Try’ techniques (IDEO, 2003)

TRY

Research MethodDescription
Behaviour SamplingSnapshot people’s activities at different times. How do pervasive products intrude in your lives?
Be Your CustomerWhat is it like to purchase your product? Actual experience of searching, buying, consuming, disposing.
BodystormingAct out scenarios with many people, using space, place, sequence, queues, etc. Test performance in context.
Empathy ToolsExperience the range of users capability for involvement under real conditions.
Experience PrototypeMock up a rough but workable prototype to simulate the experience of using the new product.
InformanceAct out scenarios observed in the field to interpret and analyse in the lab. Builds shared understanding and good for solution formation.
Paper PrototypingRapid paper based mock-ups that are manipulated to demonstrate functionality. To articulate design concepts with users.
Predict Next Year’s HeadlinesInvolve users in future design possibilities. Futuristic, wishing, unmet needs. Help separate what is needed now from what can wait.
Quick-and-Dirty PrototypingAssemble a very rough mock-up of a new feature or product to help start and refine a design.
Role-PlayingIdentify actors/stakeholders involved in design use, enact real activities in real or imagined context.
Scale ModellingSimulation technique to test arrangements of space, place, context.
ScenariosA character-rich story, to communicate (simulate) and test a plausible story in probable context.
Scenario TestingShow depictions of possible future scenarios. Share reactions, refine concepts.
Try it YourselfLike Microsoft’s famous ‘eating our own dog food’ being the first user.

PAPER PROTOTYPING
“Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person 'playing computer,' who doesn’t explain how the interface is intended to work.” (Snyder, 2003)
One of the perpetual challenges of high tech systems development is the cost of up-front design. High tech products and services have highly intangible qualities across a number of dimensions; in terms of time to deliver, dependence on other technologies, flexibility of the realization (product), dependence on rare skills and expertise. High tech products and services are themselves highly virtualized constructs or dependent themselves on the features of intangible goods; source code through to compiled application is a digital media, brittle, and based on architectural concepts that are difficult to represent, interpret and understand. Consequently high tech systems are associated with large up-front development costs before the product is usable or even visible. Compounding the problem is the observation that over 90% of a digital good’s implementation is manifest in the arcane digital back-end consisting of software architecture and computing infrastructure. The most visible aspect of a high tech product, its interface and user interaction driven aspects are a small fraction of the overall implementation. The interface is also often the last aspect to be finished for a high tech system. This delay between the conceptual ‘idea’ of the system and its eventual implementation ends up compounding the risk of systems development projects because late changes to user and interaction interfaces often necessitate fundamental redesigns of the underlying back-end architecture. All of this can be avoided with early interaction design.

Paper prototyping is one of many techniques that can and should be employed as early as possible in the development process to trial and refine design ideas surrounding user interaction. Paper prototyping is a method for rapidly constructing product mock-ups that are manipulated by users (but managed by a ‘computer’) to demonstrate design concepts and raw functionality. Paper prototyping and associated techniques for mocking up a system prototype (Table below) are effective ways of simulating and articulating design concepts with users.
Table: Some visual prototyping tools for design (Snyder, 2003)

Some visual prototyping tools for design (Snyder, 2003)

MethodDescription
Paper PrototypingPaper based mock-ups that can be put together rapidly and are operated by users and manipulated to mimic expected computer response. Paper prototypes are used to simulate functionality and test design concepts with users.
CompositesAre static graphic mock-ups that give a realistic visual impression of what the final product may look like.
WireframesWireframes are layout templates, often created within visual programming environments using the GUI toolset. Wireframe templates are usually static but realistic, employing off-the-shelf widgets and GUI elements.
StoryboardsStoryboards are sequences of sketched views of the interface or images of the product in different states. Graphical depictions of product performance, usually flowcharting the click-flow of windows, dialogs and screen sequences.

Paper prototyping is used to ‘enact’ system walkthroughs, of either the whole product or a single feature. They help to identify user paths through the system and can highlight parts that aren’t usable, accessible or that don’t work as users expect them to. Paper prototyping enables fast feedback on technical requirements and the feasibility of different design concepts. A paper prototyping walkthrough session can use the following roles: computer, expert user, scribe, and facilitator. (Exhibit below) Usability tests and pilot tests are simply more elaborate walkthroughs, with progressively fewer in-place supports for users and progressively less flexibility in reconfiguring the simulation.

EXHIBIT: Paper prototyping walkthrough session roles (Snyder, 2003)
Computer. The person who organizes and manipulates all those bits of paper (may be more than one person).
Expert user. A product team member plays this role, performing the tasks as an expert (someone who understands the interface) would be expected to do. It’s not part of this role to make bizarre mistakes or other radical departures from the norm – leave that for the real users!
Scribe. This person writes down all the missing pieces, issues, and questions that come up. It’s not always the best use of time for the entire team to discuss each issue on the spot and come to a decision. The scribe makes a list so that these things can be addressed after the walkthrough. On small teams, the scribe role may be combined with any of the other roles.
Facilitator. Strictly speaking, a walkthrough doesn’t need a facilitator, although it doesn’t hurt to have a designated person lead the session and make sure it doesn’t digress too much. Whoever plans to facilitate the usability tests should attend some walkthroughs in preparation; walkthroughs are a great way to become familiar with the functionality and behavior of the interface. For new facilitators, it’s also an opportunity to practice.

REFERENCES

Learn (ID research)

USING PERSONAS AND GOALS
User involvement and use modeling is a key success factor for systems at both proposal stage and those undergoing on-going development. A major challenge however for any system of moderate size is that the active involvement of all users is quite simply infeasible. Productive user involvement is difficult to attain at any stage in the development life cycle. A practical enabling strategy is to choose a subset of users and involve them in the process. Another strategy is to model both archetypical and atypical users, using "personas". Model users termed personas are used to construct and direct the development effort (Cooper et al., 2007).
Model users called 'personas'. They are used to construct a cast of synthetic characters complete with values, personal histories, needs and goals. Personas are not average demographic 'types', they are individual characters whose biographical detail allows designers to 'imagine' the persona's individual aspirations, choices and behaviour as realistic, plausible, meaningful. It is simply another way for designers to generate empathy with their users. It enables them to build up a cast of characters, socialised and known among the design team, in order to focus the team's design attention, to enable and contain design ideation, development action, testing, user acceptance, etc.
A persona is employed as a shared sense making device, a fictional 'identity' or a character who is imagined in putative roles wherein some future version of the product is employed. These design strategies occupy the conceptual boundary between the design-world and the use-world. Each persona can be used to...
“Develop a precise description of our user and what he wishes to accomplish.” (Cooper, 2004) 
“Personas are not real people, but they are based on the behaviours and motivations of real people we have observed and represent them throughout the design process. They are composite archetypes based on behavioural data gathered from the many actual users encountered in ethnographic interviews.” (Cooper et al., 2007)
By modelling users, through personas and goals, systems developers establish a conceptual instrument for judging the validity and quality of the system and its detailed use-behaviour. Each persona (many may be constructed) has something to say about the system, its requirements and on-going evaluation. A persona may even be produced to explore non-use of the system.

The idea of a persona as an instrument and method has broad application and impacts the whole systems development lifecycle. In particular good use of a persona ensures that goal, feature, and functionality decisions will moderate and balance design decisions driven by the technology itself. Technology (or technologist) driven ‘user’ design decisions fall into three categories: the elastic user, self-referential design, and edge cases. All three categories distort the decision making process in favour of systems development rather than actual users. The creation and use of goal directed personas goes some way to overcoming the in-built biases of the development process.

Human-Centred Learning Techniques
IDEO’s ‘Learn’ cards suggest human-centred techniques and methods to analyze, interpret, present and judge the information gathered from ethnographic and other interpretive field studies. These methods and tools may also be applied to some kinds of quantitative data gathering.
Table: IDEO 'Learn' techniques (IDEO, 2003)

LEARN

Research MethodDescription
Activity AnalysisA description of project relevant dynamics: actions, interactions, tasks, and objects of achieving goals.
Affinity DiagramsRepresent or diagram clustering of design elements with activities, goals, obstacles. Proximity, dependence and relationships
Anthropometric AnalysisHuman factors or ergonomics to assess project relevant use factors.
Character ProfilesPersonas. Archetypes of real people with real goals, lifestyle, behaviour, identities.
Cognitive Task AnalysisList, summary of all available sensory inputs decision points and actions.
Competitive Product SurveyCollect, compare, and conduct evaluations of extant and competitive products.
Cross-Cultural ComparisonsPersonal accounts of differences in situations, behaviour and artefacts in different national or cultural settings.
Error AnalysisCapturing the things that actually go wrong in the project relevant setting.
Flow AnalysisThe flow of information in existing and/or new system.
Historical AnalysisIdentify trends and cycles of product use, customer behaviour, market, and practice. Relate to timeless goals
Long-Range ForecastsNarratives of future scenarios complete with social and technological trends to predict behaviours.
Secondary ResearchSummary analysis of existing sources and 3rd party data on project relevant areas.

A cast of personas can be gradually built up during the process of field study and gathering requirements. Afterwards as the data is analyzed and interpreted we construct personas that appear relevant to the project context. The cast of personas grows initially but will gradually be whittled down as duplicates and distinctive behaviour patterns are identified. Cooper et al. (2007) suggest differentiating user personas based on their different goals (motivations) and their behavioural attributes (Table below).
Table: Identify behavioural variables (Cooper et al. 2007)

Identify behavioural variables (Cooper et al. 2007)

Behavioural variableDescription
ActivitiesWhat the user does; frequency and volume.
AttitudesHow the user thinks about the product domain and technology.
AptitudesWhat education and training the user has; capability to learn.
MotivationssWhy the user is engaged in the product domain.
SkillsUser capabilities related to the product domain and technology..

Cooper provides an example of how personas become part of the evaluation and decision making process of system design. The following discussion between the product owner (interaction designer) and the programmer deals with a persona named ‘Rosemary.’
Programmer: “What if the user wants to print this out?”
Interaction designer: “Rosemary isn’t interested in printing things out.”
Programmer: “But someone might want to print it.”
Interaction designer: “But we are designing for Rosemary, not for ‘someone.’”
(Cooper et al., 2007)

EXAMPLES: The following examples are from a number of personas developed for a project to develop a training product for a Telco billing system.

Telco systems administrator persona
Persona – Dave Taurus: Network Engineer
Industry Mobile Operator, Telco
Description
Network engineer - five years experience with Ericsson AXE and IN platforms
Responsible for configuration and maintenance of network elements
Switch database maintenance
Switch database interface guru
Hardware focused, resents the IT guys who are always sticking their noses in his switch database.
Skills
C, Sybase
Goals
1. Ensure 100% switch uptime.
2. Avoid anything that interferes with 1.
Tasks
Interface with switch manufacturer
Interface with internal business development people
Provide switch data definitions to the business/IT people
Provide access to switch data (FTP, file dumps)
Rollout new services
Occasional manual provisioning. Troubleshooting of provisioning problems.
Does not use any operational aspect of EPlus.
Will need to review event collection docs to check data transfer etc.

Telco billing consultant persona
Persona – Stephanie Billings: Background
Stephanie is 26, single and an occasional (when not travelling for work) member of the company soccer team. A bit of a lad when it comes to 'football', she's a die-hard ‘Latics’ supporter since the age of 6 when her dad started bringing her to matches. Doesn't give a toss for the Premier league - or won't until Oldham claw there way from 2nd division to 1st division to Premier...
Stephanie works as a consultant Java programmer for Accenture and is based in the Redding office. She calls the projects she works on 'gigs' and has a long list of humorous project disaster stories (though no companies are ever identified directly).
As a contractor all of Stephanie's time is accounted for, she has a personal revenue target and charges in detail down to the minute for every project she works on (even if she's back in the office doing internal stuff and not on a gig). She is a competent hardworking professional but is NOT interested in doing massive overtime (overtime is charged at time and a half, weekend work is double time).
She uses the Incode time tracker from OYOY on her Nokia 9210 Communicator to keep track of what she's doing and for billing clients.
Stef (as she is known to her friends) is passionate about JAVA and J2EE, considers herself a pretty hot JAVA programmer, highlight of her professional career to date was doing a joint presentation with Kari Kukkoaho (head of development, operations support at Nokia Networks OY) JAVAONE in San Francisco last year on OSS JAVA 3G Business Models for 3G Wireless Network. Has some product ideas about embedded JAVA and MIDP and might go off and do something about them some day.
GoalsStefanie was 'volunteered' to attend a 4 day programmer training course in the Dublin office to become a ‘certified mobile billing consultant’ because Accenture is getting primed for a project for client side implementation and integration of the EPlus billing service for a ‘major’ finance house in London.
Stefanie needs to fully understand any technology she is working on, expects all training to be an intense burst of information overload and will do a huge amount of preparation prior to the training, so wants access to all the information NOW (e.g. would like it presented like the JAVA Training Trails).
She wants to be perceived as the expert – has nightmares about not being able to answer a question, and in turn expects to be able to find answers quickly.
Training needs
Personalize training needs, expressed by questions like:
“where do I start?”
“how do I...?”
“where do I find...?”
“what do I do when...?”
“my work integrates with the rest of the team by...”

REFERENCES

Ask (ID)

"Developers must understand the application and the needs of users. It often takes a long-term relationship between users and developers, with a lot of dialog to uncover what users really need."
(Raccoon, 1995)
User participation must be part of software development.

RESPONDING TO SYSTEMS IN USE
IDEO’s ‘Ask’ methods (Table below)can be used to elicit feedback from users engaged ‘in use.’ These methods or strategies focus on user’s active participation interacting with a new technology to achieve their goals.
Table: IDEO ‘Ask’ techniques (IDEO, 2003)

ASK

Research MethodDescription
Camera JournalA written and visual diary of project relevant circumstances and activities.
Card SortOrganise cards spatially in ways that make sense. To expose mental models of device or system.
Cognitive MapsCreate a map of an existing or virtual space. The pathways they know and navigate, mental models.
CollageSelf created collage of arranged images. Used to help verbalise complex or unvocalised themes.
Conceptual LandscapeSketch and juxtapose social and behavioural constructs from participants. People’s mental model.
Cultural ProbesA visual journal for participants to build up themselves. A self generated reflection. Gathered and compared across many participants.
Draw the ExperienceAsk participants to visualise and draw the experience in their own way, with their own associations, order, relationships, theories.
Extreme User InterviewsEvaluate (ask) users at extreme ends of market (early adopters, power users, beginners) to highlight their issues.
Five Whys?Ask “why?” in response to five consecutive answers. Expose/uncover deeper attitudes perceptions.
Foreign CorrespondentsElicit inputs from others (snowball sample) to build up varied cultural and environmental contexts.
NarrationUsers perform tasks and achieve goals while describing aloud. Talk aloud protocol. Stream of consciousness.
Surveys & QuestionnairesTargeted questions to assess design, usage, interaction characterises and perceptions of users.
Unfocus GroupGather a range of tools or materials and get diverse user group to create things relevant to the design or project.
Word-Concept AssociationUsers associate words with design. Cluster user perceptions to evaluate design features & concepts. Value and priority.

What is the relevance of considering information elicitation at such at late stage in high tech systems development as implied by including the ‘Ask’ methods here in a discussion of ‘Maintenance’? The point is twofold, the first is to underscore that the nuanced view of the SDLC presented in these chapters emphasizes the interrelatedness of the various activities, phases or stages of the SDLC. The second reason is to acknowledge that for many users the release and delivery of the product is their first use of the product/system and therefore the first opportunity we have to learn how they got on. As the system is live there must be mechanisms for their experience, particularly the problems they encounter, to be recorded and directed back towards the product development initiative. Consequently, even a high tech system in maintenance mode but still used presents valid and valuable learning for future versions or future systems. In a real sense the SDLC entails doing everything at once, all activities from initial concept, through to design, development and maintenance will be in play at the same time, although to greater or lesser extent depending on the situation.

In particular, for maintenance and support, it may be productive if instead of casting support activities as outwardly assistive, to do as IDEO suggest and ask the people at the centre of your work (users and customers) to help you: ‘Ask them to help.’

Look (ID research)

TOOLS AND TECHNIQUES; SEARCHING FOR INFORMATION AND INSIGHT
Interpretive research methods often pose considerable challenges for the systems analyst and interaction designing. Knowing what to look for, to ask, to observe and record is hard enough. Knowing how to analyze, categorize, distill and present complex, entangled, messy qualitative data is also a challenge.

The IDEO method cards are an aide, to help break the impasse if the analyst gets stuck deciding what method to use or adapt for field studies and requirements gathering (IDEO, 2003). IDEO’s method cards are grouped into four categories: Learn, Look, Ask, and Try. Observational techniques are suggested by the Look category. The objective in this case is the uncover insights and understanding into what users actually do as they go about achieving their goals. The following table summarizes the Look category (Table below).
Table: IDEO 'Look' techniques (IDEO, 2003)

LOOK

Research MethodDescription
A Day in the LifeCatalogue a person’s whole day without necessarily focusing on project relevant aspects.
Behavioural ArchaeologyLook at use, wear, the detailed arrangement or organisation of use objects in their use setting.
Behavioural MappingMap position, movement, and use of space over time.
Fly on the WallObserve in context without interfering.
Guided ToursAsk the user to guide you through project relevant spaces and activities.
Personal InventoryAsk the user to reflect on and describe the things they view as important or significant
Rapid EthnographyParticipate and experience it first-hand with the user for as long as possible.
ShadowingTag-along with people through the day.
Social Network MappingNotice the relationships between people, groups. Look for identity, profession, culture, and connections.
Still Photo SurveyBuild up a visual record of key use and interaction moments over time.
Time-Lapse VideoA way of summarising activity over time, use of time, space, and location.

The cards are used as prompts for researchers involved in field studies. They also provide a shared language for research teams and their customers (users, designers, developers) undergoing the process of designing research protocols for fieldwork.

Thursday, 27 August 2015

Another topology of research methods for design

Another depiction of the spectrum of possible research methods, a way of classifying them, a way of understanding their application and use. (link to the Interaction Design Foundation article)


From the article on UX Research Communication – Report Writing