Background Concept Idea #1

This idea includes a moving London Eye and shows the busyness of the capital, maybe cars and buses going by. Almost similar to the overground map idea, without the realtime function. Just a fun animation.

Digital wall storytelling

Digital wall brainstorm

Digital wall mindmap

Digital wall Why What

Fishbone final digital wall

list of idea generation techniques

These are from experimentia.com:

• brainstorming
  
• body storming
  
• mind mapping
  
• story telling
  
• improvisation
  
• experience modelling
  
• opportunity mapping
  
• method cards
  
• wizard-of-oz prototyping
  
• inspiration chests
  
• innovation workshops

These are from creativeadvantage.com:

• Compass
• Vision Circle
• Ego Alter
• Nature Symbol
• Matrix Analysis
• SCAMPER
  

These are from ideaflow.corante.com:

• Creative Problem Solving
• Brainstorming
• Mindmapping
• 'Wouldn’t It Be Nice If ...?'
  
• Visualization
• Changing Perspective Or Place
• Storytelling
• Metaphorical Thinking
• SCAMPER
  
• Collage
• 6 Thinking Hats
• Mindmanager
• Using Random Images To Stimulate Thoughts
• Forced Associations
• Stupid & Ridiculous
• Forced Quotas
• Knowbrainer
• Ideafisher

Concept development - Idea generation - SCAMPER

Purpose

To discover ways to improve the current attributes

Duration

20 - 30 minutes

Instructions

1. Describe the key attributes or components of a situation you wish to change;
2. Apply the SCAMPER questions to your situation to generate ideas for achieving your goal.
   • S = Substitute? (other ingredients, materials, etc.)
   • C = Combine? (blend, etc.)
   • A = Adapt?
   • M = Modify, magnify or miniaturize?
   • P = Put to other uses?
   • E = Eliminate?
   • R = Reverse? (roles, etc.) or rearrange? (patterns, pace, etc.)

Facilitator Notes

For each of the letters in the mnemonic SCAMPER, you may want to start by listing the applicable components of your situation.

Source

Alex Osborn, a pioneer in facilitating creativity, developed this list of "idea-spurring questions." They were later arranged by Bob Eberle as the mnemonic SCAMPER.

Example

A bicycle has the following components: frame, pedals, drive sprocket, chain, brakes, tires, handlebars…

By applying SCAMPER, the following ideas for improving the bicycle were generated:

• Much lighter weight frames based on new materials;
• Pedal grips that strap to secure feet better;
• Stronger chains with special clamps for easier changing;
• Improved derailleur gears for rear sprocket;
• Racing handlebars for more ergo dynamic racing position;
• New rear wheel materials to replace spokes.

Concept development - Idea generation - Matrix Analysis

Purpose

To generate solutions using the Exploring Innovation Style

Duration

15 - 25 minutes

Instructions

1. Briefly describe a problem for which you need a creative solution;
2. Select the two key variables that impact this problem;
3. On a piece of paper, make a two-dimensional matrix, and label one axis with the first variable and the other axis with the second variable;
4. Along each axis, write all the possible sub-variables for each variable;
5. Draw lines from each axis so that "squares" are formed, representing the combination of one sub-variable from each axis;
6. Brainstorm ideas for each square combination, for those squares that seem most promising, or for random squares in order to spur out-of-box solutions.

Facilitator Notes

Put extra effort into determining the variables and sub-variables. This will help make this exercise most effective. Share the example below with participants to clarify the exercise.

Example

Perhaps the two most important variables in a new food product would be kinds of food and forms of food. You would list the possibilities for each variable. For each combination, such as "Meat/Drink" or "Grain/Topping," you would then brainstorm specific ideas for a new product.

Concept development - Idea generation - Nature Symbol

Purpose

To generate solutions using the Exploring Innovation Style

Duration

15 - 30 minutes

Instructions

1. Think of a goal you are working towards;
2. Select a symbol or metaphor from nature that best captures the spirit and essence of achieving that goal;
3. List the attributes of your nature symbol;
4. For each attribute, brainstorm ways to bring that attribute into a solution for achieving your goal;

Facilitator Notes

Use more than one symbol in order to access the imagination of all the participants. Can be used as an individual exercise.

Example

Suppose you want to improve the corporate culture for innovation… and the nature symbol you choose is a TREE. Some attributes of a tree are: roots, seasonality, hard outer bark, unpredictable limb patterns, leaves that breathe, etc.

For each attribute, what ideas do you get for improving the corporate culture?

• What would provide more "roots" to the culture?
• What would give better cycles and "seasons" to it?
• What could protect the culture like "hard outer bark"?
• What unpredictability might actually stimulate the culture?
• What mutually profitable exchanges might occur (like the exchange of oxygen and carbon dioxide in leaves)?

Concept development - Idea generation - Ego Alter

Purpose

To help participants step out-of-the-box by visioning solutions through the eyes of a well-known character

Duration

15 - 30 minutes

Instructions

1. Group is broken down into sub-teams of three to five people.
2. Each team is assigned a different well-known character, real or fictional (see examples below). Assume the character is now leading this project.
3. Imagine the team is at some point in the future. The solution they implemented, through the leadership of the character, is extremely successful. The future state includes many of the characteristics of the character. The process for how you got there was also strongly influenced by the character.
4. List how you got there as well as attributes of that future state, including:
   • Process attributes;
   • Technologies used;
   • How people work and work together;
   • Company (or department) culture and values;
   • Etc.

Facilitator Notes

Have the settings, problems and list of leadership figures ready in advance. There are two ways to use this technique:

• As a Visioning technique - pick a figure that you believe embodies the qualities that you wish to emulate. For example, if you want to increase the effectiveness of meetings, you might want to choose someone who is an expert at communication. (e.g. Oprah, Dr. Ruth, your old boss).
• As an Exploring technique - pick a figure at random, or one that seems the antithesis of whom you would first think of for the task. For example, how would Arnold Schwarzenegger or Marcel Marceau make meetings more effective? Have each group share their results with the others. During the debrief, identify ideas that can be practically applied to their current situations (perhaps requiring some modification).

Examples

• Queen Elizabeth I or II;
• Madonna;
• Donald Trump;
• Bill Gates;
• Sigmund Freud;
• Arnold Schwarzenegger;
• Napoleon;
• George Jetson;
• Albert Einstein;
• Your favorite teacher;
• Gloria Steinem.

Concept development - Idea generation - Vision Circle

Purpose

To generate ideas in the context of creating a group vision

Duration

10 - 20 minutes

Instructions

1. Players stay seated in a circle. Use a recorder from outside the group or have the Facilitator record all ideas;
2. Facilitator calls out a brief description of the challenge question as a future vision that the group is describing. For example, if the challenge question is "What are ideas for making our organization more innovative?" you might say "It is 5 years from now (use the date). We have been extremely successful at making this organization a great, innovative company. What does it look like?"
3. One at a time, and in any order, players call out attributes of this vision;
4. Finish the visualization when it feels that all or enough ideas have been expressed.

Concept development - Idea generation - Compass

Purpose

To generate ideas using all four Innovation Styles

Duration

20 - 30 minutes

Instructions

1. Define and describe an issue for which you want some new, creative ideas.
2. Take four to six minutes for each Style. Generate ideas using either the questions below or questions customized to your issue:
   • Visioning:
     • General: What ideas could give us an ideal future?
     • Emotion-based Ideas: What would excite us?
     • Getting Ideas from Customers: What could meet the long-term goals and strategy?
     • New Products or Services: What ideas represent the ideal wishes of our customers?
     • Organizational Change Processes: What could produce the best possible "world-class" organization?
     • Quality Process Improvement: What could give us the ultimate process?
     • Strategic Planning: How can we be ideally positioned in our industry?
   • Exploring:
     • General: What ideas could start with new assumptions?
     • Emotion-based Ideas: What would surprise us?
     • Getting Ideas from Customers: What could revolutionize the way things are done?
     • New Products or Services: What ideas would break the rules of "conventional wisdom" about our industry?
     • Organizational Change Processes: What could shake up (or "unfreeze") the organization to allow a new way of doing things?
     • Quality Process Improvement: What could we do if we started from scratch?
     • Strategic Planning: How can we rewrite the rules of competition or invent new industries?
   • Experimenting:
     • General: What ideas could combine different elements?
     • Emotion-based Ideas: What would amuse us?
     • Getting Ideas from Customers: What could be tested to see how it works under trial circumstances?
     • New Products or Services: What ideas have the right mix of features?
     • Organizational Change Processes: What could give us the best synergy among our units and capabilities?
     • Quality Process Improvement: What could combine the best features of many processes?
     • Strategic Planning: How can we synthesize different capabilities, markets, technologies, and partnerships? What can we combine to form a new solution?
   • Modifying:
     • General: What ideas could we adapt or modify to what we've done?
     • Emotion-based Ideas: What would satisfy us?
     • Getting Ideas from Customers: What could be added to what is already in place?
     • New Products or Services: What ideas would extend our current offerings?
     • Organizational Change Processes: What could preserve the best of the status quo and still move us forward?
     • Quality Process Improvement: What could improve on the current process?
     • Strategic Planning: How can we build upon our core strengths and competencies?

Scenarios description

To see a difference between use case and scenarios I'm posting a definition of scenarios from (again) wikipedia (link - title):

In computing, a scenario is a narrative describing foreseeable interactions of types of users (characters) and the system. Scenarios include information about goals, expectations, motivations, actions and reactions. Scenarios are neither predictions nor forecasts, but rather attempts to reflect on or portray the way in which a system is used in the context of daily activity.

Scenarios are frequently used as part of the systems development process. They are typically produced by usability or marketing specialists, often working in concert with end users and developers. Scenarios are written in plain language, with minimal technical details, so that stakeholders (designers, usability specialists, programmers, engineers, managers, marketing specialists, etc.) can have a common example which can focus their discussions. Scenarios are used in a number of ways:

• As a vision pieces. Vision pieces provide a high level picture of an envisioned system or product. One example is Apple's Knowledge Navigator video [1].
• As an illustration of functionality: This type of scenario illustrates the functionality the system needs to support, often connecting it to the motivations and needs of the envisioned users of the system.
• Scenarios may focus on the value offered by a system, showing how it offers an advantage over the way things are. This type of scenario may be used to 'sell' an idea within the organization that is considering developing the system.
• Scenarios may be used in the context of research, to explore, at a detailed level, the functionality a system needs to have to succeed in its daily context of use.

Vannevar Bush's As We May Think essay is a famous example of a scenario that served as a vision piece. It was the user scenario that presented the idea of hyperlinks, and illustrated the value of hypertext. It described the (fictitious) Memex machine that inspired Douglas C. Engelbart to see the potential of the personal computer, and enabled him to secure the funding necessary to design the computer mouse and first graphical user interface in 1968.

Use case description

Full text can be viewed from the title link above (wikipedia).

From my understanding now use cases are showing quite detailed path of the using the peoduct/system. Describes case goals like register user, borrow book etc. It relates primarily to information architecture and secondary to usability (my opinion). On the begining (now) we should concentrate at scenarios I would suggest (even they are generated from use cases).

Description from Wikipedia

According to Bittner and Spence, "Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful." Each use case describes how the actor will interact with the system to achieve a specific goal. One or more scenarios may be generated from each use case, corresponding to the detail of each possible way of achieving that goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by systems analysts and end users. The UML use case diagram can be used to graphically represent an overview of the use cases for a given system and a Use-case analysis can be used to develop the diagram.

A use case should:

• Describe what the system shall do for the actor to achieve a particular goal.
• Include no implementation-specific language.
• Be at the appropriate level of detail.
• Not include detail regarding user interfaces and screens. This is done in user-interface design.

Degree of detail

• A brief use case consists of a few sentences summarizing the use case. It can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record priority, technical complexity, release number, and so on.

• A casual use case consists of a few paragraphs of text, summarizing the use case.

• A fully dressed use case is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case. Fully dressed use cases are discussed in detail in the next section on use case templates.

Use case templates

There is no standard template for documenting detailed use cases. There are a number of competing schemes, and individuals are encouraged to use templates that work for them or the project they are on. Standardization within each project is more important than the detail of a specific template. There is, however, considerable agreement about the core sections; beneath differing terminologies and orderings there is an underlying similarity between most use cases.

Typical sections include:

• Use case name
• Version
• Goal
• Summary
• Actors
• Preconditions
• Triggers
• Basic course of events
• Alternative paths
• Postconditions
• Business rules
• Notes
• Author and date

Different templates often have additional sections, e.g., assumptions, exceptions, recommendations, technical requirements. There may also be industry specific sections.

Use case name

A use case name provides a unique identifier for the use case. It should be written in verb-noun format (e.g., Borrow Books, Withdraw Cash), should describe an achievable goal (e.g., Register User is better than Registering User) and should be sufficient for the end user to understand what the use case is about.

Goal-driven use case analysis will name use cases according to the actor's goals, thus ensuring use cases are strongly user centric. Two to three words is the optimum. If more than four words are proposed for a name, there is usually a shorter and more specific name that could be used.

Version

Often a version section is needed to inform the reader of the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different from the evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they may be valuable to different user groups.

Goal

Without a goal a use case is useless. There is no need for a use case when there is no need for any actor to achieve a goal. A goal briefly describes what the user intends to achieve with this use case.

Summary

A summary section is used to capture the essence of a use case before the main body is complete. It provides a quick overview, which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about. Ideally, a summary is just a few sentences or a paragraph in length and includes the goal and principal actor.

Actors

An actor is someone or something outside the system that either acts on the system – a primary actor – or is acted on by the system – a secondary actor. An actor may be a person, a device, another system or sub-system, or time. Actors represent the different roles that something outside has in its relationship with the system whose functional requirements are being specified. An individual in the real world can be represented by several actors if they have several different roles and goals in regards to a system.These interact with system and do some action on that.

Preconditions

A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case. That is, if the system is not in the state described in the preconditions, the behavior of the use case is indeterminate.

Note that the preconditions are not the same thing as the "trigger" (see below): the mere fact that the preconditions are met does NOT initiate the use case.

However, it is theoretically possible both that a use case should be initiated whenever condition X is met and that condition X is the only aspect of the system that defines whether the use case can meaningfully start. If this is really true, then condition X is both the precondition and the trigger, and would appear in both sections. But this is rare, and the analyst should check carefully that they have not overlooked some preconditions which are part of the trigger. If the analyst has erred, the module based on this use case will be triggered when the system is in a state the developer has not planned for, and the module may fail or behave unpredictably.

Triggers

A 'triggers' section describes the event that causes the use case to be initiated. This event can be external, temporal or internal. If the trigger is not a simple true "event" (e.g., the customer presses a button), but instead "when a set of conditions are met", there will need to be a triggering process that continually (or periodically) runs to test whether the "trigger conditions" are met: the "triggering event" is a signal from the trigger process that the conditions are now met.

There is varying practice over how to describe what to do when the trigger occurs but the preconditions are not met.

• One way is to handle the "error" within the use case (as an exception). Strictly, this is illogical, because the "preconditions" are now not true preconditions at all (because the behaviour of the use case is determined even when the preconditions are not met).
• Another way is to put all the preconditions in the trigger (so that the use case does not run if the preconditions are not met) and create a different use case to handle the problem. Note that if this is the local standard, then the use case template theoretically does not need a preconditions section!

Basic course of events

At a minimum, each use case should convey a primary scenario, or typical course of events, also called "basic flow" or "happy flow". The main basic course of events is often conveyed as a set of usually numbered steps. For example:

1. The system prompts the user to log on.
2. The user enters his name and password.
3. The system verifies the logon information.
4. The system logs user on to system.

Alternative paths

Use cases may contain secondary paths or alternative scenarios, which are variations on the main theme. Each tested rule may lead to an alternate path and when there are many rules the permutation of paths increases rapidly, which can lead to very complex documents. Sometimes it is better to use conditional logic or activity diagrams to describe use case with many rules and conditions.

Exceptions, or what happens when things go wrong at the system level, may also be described, not using the alternative paths section but in a section of their own. Alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and, if appropriate, where they rejoin. The intention is to avoid repeating information unnecessarily.

An example of an alternative path would be:

1. The system recognizes cookie on user's machine.
2. Go to step 4 (Main path)

An example of an exception path would be:

3. The system does not recognize user's logon information

4. Go to step 1 (Main path)

According to Anthony J H Simons and Ian Graham (who openly admits he got it wrong - using 2000 use cases at Swiss Bank), alternate paths were not originally part of use cases. Instead, each use case represented a single user's interaction with the system. In other words, each use case represented one possible path through the system. Multiple use cases would be needed before designs based on them could be made. In this sense, use cases are for exploration, not documentation.

An Activity diagram can give an overview of the basic path and alternatives path.

Postconditions

The post-conditions section describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.

Business rules

Business rules are written (or unwritten) rules or policies that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of requirement. Business rules may be specific to a use case or apply across all the use cases, or across the entire business. Use cases should clearly reference BRs that are applicable and where they are implemented.

Business Rules should be encoded in-line with the Use Case logic and execution may lead to different post conditions. E.g. Rule2. that a cash withdraw will lead to an update of the account and a transaction log leads to a post condition on successful withdrawal - but only if Rule1 which says there must be sufficient funds tests as true.

Notes

Experience has shown that however well-designed a use case template is, the analyst will have some important information that does not fit under a specific heading. Therefore all good templates include a section (eg "Notes to Developers") that allows less-structured information to be recorded.

Author and date

This section should list when a version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents. The author is traditionally listed at the bottom, because it is not considered to be essential information; use cases are intended to be collaborative endeavors and they should be jointly owned.

Idea for oystergotchi character design

I was thinking about how to resolve some problems with the character we could have - how to cover with one character all target audiences (ages, gender, nationalities etc.) and how to keep people interested in using it.

And I came up with this:
TFL is already using some artists to do images for their printed tube map. We could adopt this tradition and make it even more interesting by incorporating a competition into it.
We could suggest a competition held once a year where designers (new graduates, students, also already well known illustrators) could participate. They would be asked to design Oystergotchi character. 12 the best designs would be chosen and designers asked to create full set of expressions of the character. Each character would be used for one month with the name of the designer shown.
As the tube is very public place used with huge amount of commuters, it's a great place to showcase yourself if you are a designer. Also winning a competition for such a big government company looks great in the portfolio. I believe it could have a great response.
And this would bring extra layer to the project. The character would be regularly changing so people wouldn't get bored and art/design would get into the awareness of the public.

And...
We could do a small competition already for the major project itself. We could ask designers if they would be interested in designing the character for us and have nice set of oystergotchis already for the exhibit. The designers could be students of our uni or we could also approach practicing designers, there is lots of email contacts in the Computer Arts magazine...

So...
What do you think? :-)

Idea generation findings

During the meeting on Friday 6th June I decided to use 3 methods of idea generation: mind mapping, brainstorming and storytelling.

My findings / opinions about results

Mind mapping

• very good to map what everything needs to be done, where to look at, keep a good overview of some specific area (for example create and constantly keep changing map of interactive media, update every time when new technology, sub area appears)
• takes very long to create and link correctly all sections and subsections if it should make sense
• don't find it useful if instant idea generation is needed
• can be good background to look at while brainstorming as it can have covered many areas which needs to be considered
• I would suggest to have the all main areas which are used for all projects covered by mind maps created in advance and create small sub areas and specific project areas mind maps before brainstorming
• using software is useful because it allows to move, reposition and reconnect the sections, topics and single phrases
  

Brainstorming

• I have participated brainstorms before in the company I was working for and found it very useless
• for that reason I have research deeply the topic to find out as much as possible about that and learn how to run the brainstorming properly and get good results or at least some results
• I have used brainstorming software to make ideas flow quickly (I have many spelling mistakes there... :-)) This was really helpful.
• on the beginning we were keeping quite tightly around possible and realistic uses and technologies, generally around what we were discussing already before. I supported bringing up everything relevant and mainly irrelevant ideas and topics (I have personal experience that irrelevant ideas are the best to use for 'out of the box' ideas) and from that point we had lots of fun and brought huge amount of ideas and topics into the subject.
  
• I will analyze the ideas. The suggestion from my research is to do excellent/interesting/useless selection. We were writing down ideas as a single words, things (technologies, uses etc.) we could use but not full concepts. It worked a bit more like quick mind map of everything which is possible to use. This should be taken now and connected together.
• as the excellent to useless technique could lead into moving away from the main concept of the project, I decided to use different approach. I'll separate the ideas into the most relevant/partly relevant/irrelevant in comparison to the main concept.
• also will try to take all those separated ideas and connect them together into the new sub-concepts or use separately.

Storytelling

• very useful technique to highlight issues the current state has and find out what solutions could/should be used. Also good source of assumptions to take and test.
• I used this technique to create a base for questionares Taz will prepare and use for survey.
• I found it a entertaining way to locate issues and assumptions. It also brings much longer list of them within very short time of generating the stories

Project storytelling

Full size file here

Project brainstorm

Full size file here

Project mind map

Full size file here