A commonly held belief among designers is that quality ideas come from having a large quantity of ideas, because generating wild and diverse ideas can spark creativity and innovation. This design ideation is often accomplished through activities such as brainstorming, sketching, and storytelling, all of which tend to be driven by designers. However, as technology becomes increasingly personal, ideation conducted by designers in isolation can lead to faulty assumptions that can adversely impact the user experience.
By ideating with users, designers can create new technologies that embody the needs and values of their users. Unfortunately, engaging users early in the product development cycle requires significant planning and expense beyond the capabilities of design teams on tight budgets and timelines.
The DesignLibs Method
To help address the need to easily engage with users early on to generate novel ideas quickly and at large scale, we developed a new method called DesignLibs. In a nutshell, the method requires a designer to create a scenario for a new technology, remove keywords from the scenario, and then have potential users fill in the missing keywords.
In addition to this standard DesignLibs method that allows users to see the scenario while filling in the blanks, we developed two other formats: Q&A and MadLibs (see Figure 1). The Q&A format asks users to answer specific questions without revealing the scenario. The designer then inserts their answers into the scenario she created and reflects on it for inspiration. The MadLibs format is similar to Q&A, but instead of answering questions, users are asked to provide words of a certain type. This format works just like the children’s game of Mad Libs® (www.madlibs.com).
To understand how DesignLibs performs as an ideation tool, we conducted a study scenario for an application that detects and responds to the user’s mood. More than two hundred participants completed a web-based survey. Each participant was presented with one of the three DesignLibs formats, which resulted in eighty completions per format. A team of six designers who were not involved in any other part of the project commented on the resulting scenarios and rated them for feasibility, usefulness, and creativity. Table 1 shows some of the scenarios produced by the three conditions and the feedback we received from the designers who evaluated the scenarios.
|DesignLibs Format||Results||Designer Feedback|
|Fill in the blanks||“When the device senses that he/she is stressed, it responds by signal.”||“I wouldn’t want to wear a head laser, but I kind of like the simplicity here: if you’re stressed, the device lets you know.”|
|“When the device senses that he/she is gloomy, it responds by heating slightly.”||“Really like this idea; not sure if it’d necessarily produce the desired effect.”|
|“When the device senses that he/she is calm, it responds by humming.”||“Interesting ambient-ish feedback that seems like a sympathetic computerized response.”|
|Q&A||“When the device senses that he/she is upset, it responds by joking.”||“Telling a joke in response to something that someone is upset is a simple and possibly effective approach.”|
|“When the device senses that he/she is angry, it responds by cooling.”||Changing temperature in response to moods is interesting! What else can you do with that?”|
|“When the device senses that he/she is good, it responds by play.”||“While technologically ill-specified, this is the only scenario so far talking about babies as users, and suggests the idea of instigating play when the baby feels good and shouting (perhaps to alert caregivers?) when he/she feels bad. Not useful as specified but opens up other interesting ideas.”|
|Madlibs||“…When the device senses that he/she is joy, it responds by standing.”||“It makes me think of building just an avatar that responds to emotions relatively passively through body language (for example, standing up and looking alert when the user is happy)…”|
|“When the device senses that he/she is sleepy, it responds by kick.”||“The opposite of this, whatever that is, might be a good solution.”|
|“When the device senses that he/she is glum, it responds by cook.”||“Having something cook when you’re glum would be lovely!“|
According to the designers’ ratings, the fill-in-the-blanks method produced more feasible and useful scenarios than the Q&A or MadLibs formats. This finding wasn’t unexpected since neither Q&A nor MadLibs allow users to see how the words they provide will be used. Consequently, the results can be absurd without users ever realizing it.
What was surprising is that the Q&A method produced scenarios that the designers rated as more feasible and useful than the MadLibs scenarios, despite the fact that in both cases users couldn’t see the context. The Q&A method must have helped users decontextualize their experiences and reflect on their behavior without being biased by expectations for how a technology should work.
While it may seem that the MadLibs condition was an inferior format, designers still found the scenarios it produced useful. Sometimes even outlandish scenarios can be thought-provoking.
Before You Put It into Practice
The responses from the designers who participated in our study, combined with our own reflection on the scenarios, led us to conclude that each of the DesignLibs formats works best at generating certain types of scenarios (see Table 2).
|DesignLibs Format||Outcome||When to Use|
|Fill in the blanks||No||Yes||Yes||When exploring a new design topic|
|Q&A||Yes||Yes||Yes||When trying to encourage personally relevant responses|
|MadLibs||Yes||No||No||When needing inspiration after having worked on the same design topic for a while|
The fill-in-the-blanks method is best for producing a large number of feasible and useful ideas and should be used when designers are exploring a large design space that’s relatively new to them. The MadLibs condition, in contrast, seems to be most suitable for generating divergent ideas, most valuable after you have worked in a space for some time. Finally, the Q&A method may be better suited to situations in which designers would like users to provide feasible ideas that aren’t biased by expectations of how technology should be used.
As technologies play a more significant role in users’ personal lives, it becomes essential to include users early on in the product development process. By being quick and easy to develop and deploy, DesignLibs is a great tool for accomplishing this goal. We envision DesignLibs as a useful part of a designer’s toolbox and hope you’ll consider experimenting with the tool as a means to generate ideas. If you do use DesignLibs in your work, please let us know how it went!
Figure 1 text
There are three versions of a form where a user can fill in the blanks to build a story.
Version 1: Fill in the blanks
[name] is a a [age]-year old [occupation] who has been struggling with a lot of job-related stress. He/she decided to try a new application to relieve stress, which runs on a/an [computing device[ to help improve his/her mood.
The application senses his/her mood through a device he/she wears on his/her [body part].
When the device senses that he/she is [mood word], it respond by [action word].
Version 2: Q&A
1. The first name of someone you know well is [ ].
2. He/she is [ ] years old.
3. His/her occupation is [ ].
4. he/she would like to own a computing device such as [ ].
5. He/she might be comfortable wearing a small computing device on his/her [ ].
6. When he/she is in a/an [ mood ], you would like to [ ] for him/her.
Version 3: MadLibs
1. A person’s name: [ ]
2. An age: [ ]
3. An occupation: [ ]
4. A computing device: [ ]
5. A body part: [ ]
6. A mood word: [ ]
7. An action word: [ ]