should our software development process begin with storyboarding?

45
Should our software development process begin with storyboarding? Mémoire – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers Anna van der Aa May 2014

Upload: ensci-les-ateliers

Post on 06-Apr-2016

214 views

Category:

Documents


1 download

DESCRIPTION

Mémoire Anna Van der AA Mastère Innovation By Design à l'ENSCI - Les Ateliers http://www.ensci.com/formation-continue/innovation-by-design/diplomes/these/article/19779/

TRANSCRIPT

Page 1: Should our software development process begin with storyboarding?

Should our software development process begin with storyboarding? Mémoire – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers

Anna van der Aa

May 2014

Page 2: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014

Acknowledgements

My sincere thanks to Michael Fleming for his professional support, to Mathias

Béjean for his unfailing direction and encouragement, and to Ann-Marie Yee for

her attentive review. Thanks also to the participants of the workshops discussed

here and for permission to include their images. Lastly, thanks to the staff and

students of the transformative course Innovation by Design at ENSCI Les Ateliers.

Page 3: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014

Contents

1. Introduction ................................................................................................ 1

2. Elaboration of the question: Should our software development process begin with

storyboarding? ................................................................................................... 9

i. Why and when might something new need to be introduced? .................... 9

ii. Why might this ‘something new’ involve visual storytelling? .....................10

iii. Why might storyboarding be suitable? ...................................................10

iv. Where has this been tried and what were the results? .............................13

3. Comparison of two problem-framing workshops with and without storyboarding .17

i. Description of workshop without storyboarding .......................................17

ii. Description of workshop with storyboarding ...........................................20

iii. Criteria used for comparison ................................................................22

iv. Some images from the symbolic storyboarding exercise ..........................23

4. Results and discussion ................................................................................27

i. What were the significant differences between the two workshops? ...........27

ii. What were the benefits or otherwise of using storyboarding? ...................29

a. Contextual relevance of ideas .........................................................29

b. Physical engagement during exercise ..............................................30

c. Level of fun and enjoyment ............................................................31

d. Economy of transmission ...............................................................32

5. Conclusion .................................................................................................36

6. Further observations/reflections/questions .....................................................37

i. What effect would it have to confine the storyboard into frames? ..............37

ii. Would it still be beneficial to do the written tasks? ..................................37

iii. What hurdles might need to be overcome for storyboarding to become a natural part of the development process? .........................................................38

7. Bibliography ...............................................................................................39

i. Books ................................................................................................39

ii. Academic Articles ................................................................................39

iii. Web references ..................................................................................40

8. Appendix ...................................................................................................40

i. Research Questions - Wikström, Anders, Storyboarding – Framing and Reframing Opportunities in the Front-Front end of Innovation, 2013 ....................40

Page 4: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014

Our experience is that the effect of pictures is frequently greater than the effect of

words, especially at the first stage of getting new knowledge.

Otto Neurath, 1936

Within product and service development today the use of storyboards is common

in order to explain a future service or the experience of a new service. However,

the application of storyboarding as a process tool is new. Also the area of use is

new, pre-brief activities.

Anders Wikström, 2013

Page 5: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 1

1. Introduction

The post graduate course Innovation by Design exposes students to a great deal

of stimulating input from the design community. These presentations and

discussions, along with the additional reading that they have prompted, have

been the source of much inspiration to me. With the intention of sharing some of

the newly gained insights with our software development team in Sydney, I

organised a week long workshop for our staff there in March 2013.

The workshop was initiated by way of a presentation intended to lift the team’s

attention from the detailed tasks at hand and to help them appreciate where our

software fits in our clients’ worlds from a broader perspective. Influenced,

amongst other things, by Norman & Verganti’s paper Incremental and Radical

Innovation, I wanted to warn against the dangers of simply continuing to

incrementally improve our legacy software offering. Considering our market-

leading position in this domain, by failing to innovate we could set a trap for

ourselves. This potential vulnerability provided the justification to begin reviewing

our processes more extensively by experimenting with different ways of

approaching our work, such as integrating principles from design thinking (as

described in Tim Brown’s book Change by Design).

One of the main goals of this particular workshop was to encourage the team to

better tolerate the lack of resolution that must persist if more than one solution is

to be explored or even entertained for a given design problem. Historically, our

approach has been to implement the first workable solution that promises to

provide the necessary functionality, rather than first generating a widely divergent

range of potential solutions to prototype and test. Our typical approach is not a

method that we have intentionally adopted but is more of a pattern of behaviour

that we have fallen into. If we want to see more radical innovation in our software

however, we will need to take a more experimental approach to idea generation.

During the workshop we watched recorded videos of different clients performing a

particular activity with our software. The participants were discouraged from

immediately deciding the ‘best’ way to solve any problems that they noticed and

were instead invited to withstand the resulting tension until various options were

proposed and actually tested using paper prototypes.

Upon returning home to Paris, something that continued to intrigue me was the

fact that even though the recorded situations portrayed a number of clients

performing similar actions repetitively, some of those attending the sessions were

more easily able to connect with the client perspective and make contributions

Page 6: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 2

which were in line with what the clients might need, whereas others made

suggestions which showed no real empathy or appreciation of what was actually

occurring in the situations presented.

As the workshop facilitator I was able to direct the participants back to the

problem facing the clients however I became curious as to how the process could

be transformed so that the participants would have a greater appreciation of what

was actually occurring in the clients’ world. After all, the intention of the workshop

was to provide methodological tools for future exploration of client problems.

Outside the workshop context it would not be possible to steer the thinking away

from irrelevant solutions, while nevertheless encouraging creative ones.

I became intrigued by whether it might be possible to somehow influence the

developers to more naturally align their thinking to the clients’ problems, and

subsequently began to investigate this theme. Robert B. Cialdini’s fascinating

book Influence describes aspects of human perception and interaction harnessed

by magicians and con artists. Manipulation was not really what I had in mind

however, and I found myself steering more towards the idea of “cultivating

serendipity” as discussed by Raghu Garud et al. in their article Path Dependence

or Path Creation.

My preoccupation was to do with how to plant a seed in the mind of a developer

that might grow into a transformed outcome in the software for the client. Notions

of sense-making and design fixation seemed relevant, since it was this process of

turning one’s detailed attention to something in order to thoroughly understand it

while remaining open to new insight on the bigger picture that we needed to

better navigate.

At this point I began to suspect that some kind of storytelling might hold a key

and went looking for answers in David M. Boje’s Storytelling Organizations, Ty

Montague’s True Story: How to Combine Story and Action to Transform Your

Business and Whitney Quesenbery and Kevin Brooks’ Storytelling for User

Experience. The appeal of storytelling methods was in their potential to have an

impact at both the macro (organisational) and micro (individual) level.

As part of the introductory presentation to launch the workshop I had shown a

‘propaganda’ video which included heavily edited highlights of repetitive client

behaviour to drive a particular point home. At one point I considered exploring the

power of such propaganda to somehow bring about the change I was looking for.

One of the problems with this approach however is the danger of one person (the

editor) focussing on the wrong story to tell before the problem space had been

more widely explored by the group. Another is that, even when short, watching a

Page 7: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 3

video takes time and is a passive activity. It was already evident that observation

of the client activity recordings would be an important part of the process, but this

requires dedication and a certain amount of motivation to begin with. It was the

seed of this initial motivation that I wanted to sow. I continued my search.

The initial presentation also included a rough sketch to convey this idea that we

were tending towards incremental innovation rather than looking at client

problems with fresh eyes in the current technological context. It attempted to

show that we might be open to attacks from competitive start-ups with different

ideas. The sketch was intended to encourage the use of drawing as a tool for

thinking and communication and was left deliberately unpolished to ensure

everyone felt good about their own drawing skills by comparison. Looking back I

realise this was my first storyboard.

Page 8: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 4

In the following months, while continuing to ponder how to stimulate such a shift

in thinking, I experimented more with this particular medium and started

producing small comic strips (calling them UX Comix) to capture and depict client

problems identified in the recordings of the clients using our software. I soon

came across Kevin Cheng’s book See What I Mean: How to Use Comics to

Communicate Ideas which was extremely helpful in many ways. The book is

squarely aimed at the business context and, as well as providing practical

guidance regarding how to construct a comic strip, it more importantly grants

permission to exploit this modern medium within the software development

context, giving examples of its use by innovative technology firms such as Google

and Yahoo.

As Cheng puts it, “Comics are like a Trojan horse for information. The format of

comics creates a natural gravitation toward them. They have a low barrier, are

quick to read, and perhaps most importantly, are entertaining. Providing useful

information in a comic is almost unfair to the reader because the humour and

light-hearted nature lowers the reader’s defences.”

The comic strips, by their storytelling nature, provide a setting in which to place

quotes collected from the clients featured in the video recordings. I wanted to

somehow emotionally connect the development team with the heart of a given

problem in a way that would quickly describe the problem itself, provide the

overriding context which would create direction, and stimulate natural motivation

within the development team, without limiting the potential solutions. This in turn

would hopefully provide the incentive to delve deeper into the problem by taking

the time to watch the user research recordings.

Page 9: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 5

Interestingly, the developers have enjoyed reading these comic strips (published

in the company’s internal monthly newsletter), despite feeling the ‘ouch’ of an

occasional pointed message. Recently, when I showed one of my UX Comix to

some clients, they laughed ruefully, showing their identification with the story

presented. When I showed the same comic strip to one of the developers, rather

than becoming defensive, he became curious regarding the situation and wanted

to know more about the problem so that he could begin to consider suitable

solutions.

This was a very encouraging moment and at that point I became more confident

that there was value in this approach and that it would be worth continued

exploration.

Certain aspects of the comic strips drew my attention:

The comic strips can be consumed extremely quickly, unlike a video which

requires the passage of time and a different kind of mental processing because

of the dense content.

When user situations and quotes are used, the comic strips ring true and there

is an almost instant identification with the situation described.

If a suitable comic strip cannot be created for a subject area, this may reveal

that the subject area and the typical problems encountered are poorly

understood.

It was this third point in particular that suggested to me that storyboarding might

be worth investigating as a method to explore what is known and unknown about

the client domain.

As my thinking continued to develop around this area my supervisor, Mathias

Béjean, noticed and brought to my attention the work of the Swedish researcher

Anders Wikström who was concurrently completing a doctorate at the School of

Innovation, Design & Engineering at Mälardalen University Sweden. Wikström’s

timely dissertation, presented in September 2013 with the title: Storyboarding –

Framing and Reframing Opportunities in the Front-Front End of Innovation, serves

as a key reference for my research and will be discussed in the context of the

questions raised in the various sections below.

The initial workshop held in Sydney loosely followed the design thinking approach

of ‘inspiration’ followed by ‘ideation’ and then ‘implementation’. The inspiration

phase consisted of viewing the user research recordings while identifying the tasks

performed by the users and collecting these as written phrases. The tasks

captured were eventually sorted, categorised, abstracted and summarised. It

Page 10: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 6

turned out that this was the part of the workshop I wanted to revise if the

exercise were to be repeated, in the hope of finding a more physically engaging

activity, and one which would lead to greater empathy with the client context.

After hearing about Wikström’s research using storyboarding in the problem

exploration phase I began to wonder whether the creation of comic strips or

storyboards, instead of written phrases, might help our development team absorb

the incoming information differently. I wondered how it would affect their

appreciation of the client context, and whether any detail would be lost compared

with that gathered by the written analysis.

While waiting for Wikström’s research to be published I began to direct my

exploration of storytelling further towards visual narrative, attempting (in the

limited time available) to investigate where this has been used in the business

context to explore a problem space. Of course visual thinking itself has long been

used in professions such as architecture and design. Storytelling is also becoming

much more acceptable as a form of communication in the corporate context. The

combination of the two, represented by the storyboard, captured my attention.

In his book Back of the Napkin Dan Roam states: “We can use the simplicity and

immediacy of pictures to discover and clarify our own ideas, and use those same

pictures to clarify our ideas for other people, helping them discover something

new for themselves along the way.” It was this ‘discover something new for

themselves’ in particular that hinted at the potential use of visual thinking not just

to communicate something that was already understood but to explore something

that was not yet understood.

I planned a subsequent workshop, using the same raw material, with another of

our development teams; this time with the express purpose of experimenting with

storyboarding during the exploration of the client problem space, that is, the

observation (or inspiration) phase of the workshop. I was curious to see what

differences might emerge from the altered process.

As soon as the workshop began it occurred to me that it might be too much to ask

for the production of formal storyboards (with the implication of format and

structure and the potential pressure of artistic merit). Developers fed on a steady

diet of written specifications for many years might feel intimidated or even

discouraged while attempting to master the art in the short time available (two

days) for this aspect of the week-long workshop. Also, I wanted to ensure

everyone participated and didn’t leave the drawing to a talented few.

Page 11: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 7

Instead, I decided to start by encouraging the group to identify all the elements in

the story that were revealed (or implied) by the video recordings (inspired by Dan

Roam’s approach to use questions such as who and what, how many, where and

when). While watching the research videos, we individually noted as many of

these kinds of elements as possible and began to think of how we could represent

them with a simple drawing.

We came together to compare the various drawings and to agree on which ones

best represented each element. We deliberately tried to reduce these symbols to

their simplest expression for easy reproduction and recognition.

Page 12: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 8

Fascinatingly, it turned out that these symbols quickly became a visual vocabulary

which we could use, together with arrows, speech bubbles and text, to create very

rough sequential stories which visually represented a particular scenario derived

from the client context. Because these were designed to be open and exploratory

rather than closed and communicative they were produced in a loose format more

like a flowchart connecting the individual symbols (each drawn on its own sticky

note). To differentiate this from classic storyboarding organised into frames, and

to emphasise the use of icons or symbols as an important part of the process, I

have begun to refer to this as ‘symbolic storyboarding’.

This is discussed in more detail below, along with the outcome of the workshop,

some conclusions and further questions arising from the research.

Page 13: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 9

2. Elaboration of the question: Should our software development

process begin with storyboarding?

i. Why and when might something new need to be introduced?

We have an excellent relationship with our clients and users and yet we still seem

to struggle to implement changes which transform the way they work. We have

good structures for feedback and the clients themselves are well organised,

cooperative and eloquent. We have open communication and easy access to

clients and users and our analysts and developers are enthusiastic and committed

with a clear process.

Despite our clients’ commitment and goodwill we do not seem to be successfully

aligning ourselves with their true requirements in a way that they find fully

satisfying, even though we are technically fulfilling the expressed and documented

requirements, and providing the functionality that they request. To achieve a

different outcome in future, and to ensure that we begin to really delight our

clients before someone else does, something needs to change.

Because we seem to be regularly missing the mark in terms of how the

functionality is served to the customers via the software, this suggests that we

may need to review the ‘front-front end’ or ‘fuzzy front end’ of our software

development process during which we explore the client domain. Perhaps we are

not correctly identifying suitable target outcomes from the user perspective in the

first place. This leads me to wonder whether those providing the solutions

sufficiently appreciate our clients’ environments and the stories of their daily

work.

I suspect that Dan Brown in Designing Together captures something of what we

are missing when he talks about the difference between providing an explanation

and having an understanding of something. “If you know that humans perceive

different frequencies of light as different colors, you have an explanation. If you

personally look at the world through a prism, visit places where color sets

different moods, and then listen to people talk about color in their lives and the

way color touches their memories and is mixed up with deep, identity-level

notions like ‘home’, you begin to develop an understanding.”

If we are to make this transition from simply explaining the client context and

meeting its functional requirements, to really understanding it in a way that

enables us to have innovative ideas that bring new meaning to our clients’ work,

Page 14: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 10

then it will involve changes for individuals at a practical level as well as a strategic

shift in focus for our organisation as a whole.

ii. Why might this ‘something new’ involve visual storytelling?

More and more is being uncovered about the way the human brain processes

information and a large proportion of this processing seems to be dedicated to

visual input. We naturally seem to look for patterns and associations and use

visual methods when trying to make sense of incoming information. As Otto

Neurath discovered many years ago, it is particularly at the early point of sense-

making, for example when exploring a new environment or absorbing new

information, that visual input seems to have a significant impact.

As market leaders and experts in our domain we may be at risk of becoming

complacent and failing to notice changes in our clients’ business processes. It is

important that we make a point of looking with ‘fresh eyes’ to ensure that we

understand technological or other changes that are influencing their workflows.

Because it is precisely at this fuzzy-front end of innovation that we appear to be

failing, introducing a visual activity at this early stage in our process might make

an important difference. Exploring the client domain using some kind of visual

approach might allow us to see it differently which will hopefully bring a better

understanding of our clients’ true requirements, and consequently, improved

solutions.

While images help us absorb new information, stories help us see the bigger

picture. As Quesenbery and Brooks note “Stories that describe the world as it is

today help us understand that world better. They not only describe a sequence of

events, but they also provide insight into the reasons and motivations for those

events.” Storytelling is an ideal way of navigating through the client setting. Not

only does it bring examples of the clients’ business workflows to life, it usually

invites an emotional connection.

It seems then, that the ideal tool for gaining a new perspective and, potentially,

new meaning, will involve some kind of visual storytelling.

iii. Why might storyboarding be suitable?

By way of background, in 2013 I facilitated two workshops with two different

development teams. The purpose of these workshops was to review and perhaps

renovate our thinking about software development.

This first workshop used a written approach to capturing and analysing key

information about the client domain while observing video recordings of clients

Page 15: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 11

working with our software. While the willingness to contribute was not lacking, the

exercise itself did not seem to inspire action, and initial enthusiasm soon waned.

The synthesis and analysis ended up being largely driven by a motivated few with

others taking more passive roles. It was my impression from the behaviour of

some participants that this particular exercise was perhaps quite taxing energy-

wise.

Watching the videos is an important aspect of ‘soaking’ in the user’s world, and it

is necessary to watch more than one to begin to see patterns emerging. This can

be quite a static and tiring activity and I wanted to encourage an increased

engagement on the part of those watching the recordings. That had been the

initial purpose of the task-noting activity and I wondered if using a more visual

approach to documenting these observations might be a key to influencing energy

and motivation levels.

After the first workshop, while trying to find ways to bring about a change in the

way our developers perceive client and user problems, I began to experiment with

presenting the information in the form of small stories contained in drawn strips.

These are essentially storyboards or comic strips which are populated from user

research including user quotes and realistic situations.

There is a little humour to make the point but care is taken to avoid harsh

criticism. The intention of these comic strips is to expose the way the clients and

users are actually behaving and thinking in a way that might be consumed by the

developers via different brain pathways.

The comic strip is presented with as little detail as possible, while conveying the

context. This leaves room for the imagination to move and to begin its creative

search for solutions. The hope is that there is a readier connection with the

situation since the information is being presented visually and with greater

emotional impact in the story form. It is my strong conviction that developers

have a natural desire to solve problems well and to do good, however these good

Page 16: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 12

intentions sometimes miss the mark due to poor appreciation of the client domain

and therefore inappropriate problem framing.

With these comic strips I am perhaps encouraging a kind of design fixation, that

is, a fixation on one problem. I do believe that a clear problem definition helps in

the evaluation of potential solutions. However this does not resolve the broader

issue which is how to help the developers think differently about the problem

space in the first instance, while they are exploring the problem themselves,

rather than waiting for someone like me to capture and communicate it in

storyboard form.

Importantly, while creating the comic strips, I noticed that the act of telling the

story in this visual way very quickly highlighted areas where I did not have the

domain knowledge necessary to present a convincing scenario. It was this

realisation that led me to the potential value of storyboarding as a mechanism for

transforming the early phase of our design process, and so to experiment with

this activity in the second workshop.

Of course in the fuzzy-front end of innovation there are an infinite number of

ideas and observations to be had within any given context, and the more minds

involved in seeking these out and portraying them the better. I'd like to see the

entire team identifying and capturing new problems, for us to inhabit the space by

turning our attention to it with as much of our interactive capacity as possible, so

that we can think innovatively through the clients’ own stories. This is why I'm

interested in the collaborative visual thinking and storyboarding approach for

'absorbing' the context more thoroughly.

Page 17: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 13

iv. Where has this been tried and what were the results?

Storyboards are becoming more commonly used in the field of user experience (UX) for describing potential software or service

design solutions to clients or other stakeholders. Their purpose in this context is typically to communicate how the user will

interact with or experience a proposed solution. For those interested, a few relevant internet articles are included in the web

references section at the end of this document.

The use of storyboards for the explicit purpose of exploring a problem domain is discussed in the recently published doctorate

paper Storyboarding – Framing and Reframing Opportunities in the Front-Front End of Innovation by Anders Wikström.

Wikström uses a number of different research methods to explore storyboarding as a tool for developing knowledge about a

situation and for framing an area of interest.

While the entire study is pertinent, including the discussion on design thinking, visual thinking and narrative as providing cognitive

tools for reflective practice, of particular relevance to this present discussion are the sections 4.3.2 Study F, storyboarding vs.

written and 4.4.1 Study G, testing hypotheses.

Portions of these sections are copied here for convenience as I will refer to them below. Please note that these are selected

highlights. Interested readers are encouraged to read these sections in their entirety in the original document. Wikström’s research

questions, revealing his key concerns, are also included in the Appendix.

From Wikström 2.2 Methodology:

The overall goal of this research is to support companies in developing their innovation capability. During the research sub-goals have been

developed, such as enhancing knowledge in how design thinking, visual thinking and narrative support the front-front end of innovation. This has

then led to proposing a tool, storyboarding, derived from my theoretical exploration of design thinking, visual thinking and narrative and its effect on

the front-front end of innovation. This has also been the goal of this research, to create knowledge regarding storyboarding in the front-front end of

innovation, providing new knowledge in the discourse of innovation management.

Page 18: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 14

From Wikström 3.5:

What happens when telling stories is that you pick a situation to focus on. This situation constitutes a part of a culture; when knowledge is

developed about this specific situation, knowledge is also developed about the culture in which the situation occurs. As Beckman and Barry (2007)

explain culture plays an important role in product choice, usage, and resistance, and with this knowledge we can understand the meaning in the

situation. The idea behind this is that by telling stories you can understand the culture in the situation and through this create meaning in the

situation, both by making sense of the situation and by opening an opportunity for innovation of meaning.

From Wikström 4.3.1:

The development of storyboarding in pre-brief activities seems to promote an emotional understanding of the situation of interest. This indicates that

storyboarding supports an empathic approach towards the situation. Empathy in understanding a situation or issue is seen as a key criterion when

using a design-thinking approach.

From Wikström 4.3.2 Study F, Storyboarding vs. written:

Through the development of a storyboard we can see that idea generation during and after storyboarding becomes more focused if we create a

common mental image of the situation.

Page 19: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 15

From Wikström 4.3.2 Study G 4.4.1:

Hypothesis 1. Type of innovation: A

storyboarding brief is focussed on meaning

while a written brief is focussed on function.

The result from the experiment shows that

Hypothesis 1 cannot be confirmed…

What was found in this study was that there is a

difference but not the expected one; the

difference lies in the fact that storyboarding

forces a focus on both meaning and function

while written briefs focus on either meaning or

function. This finding is interesting since it

forces the team to focus on meaning when

using storyboarding in the pre-brief activities.

The other interesting thing here is that written

briefs tend to focus on either meaning or

function.

Hypothesis 2. Type of scope: A storyboarding

brief is narrow in its scope while a written brief is

broad.

The result from the experiments with respect to

Hypothesis 2 is clear…

A narrow brief is more delimited and specifies

more details than the area of interest. A broad

brief opens up for more opportunities and

enables solutions outside the area of interest.

The narrowness of storyboarding supports

management in providing a strategic direction

for the team; this also removes hidden fixations

of the teams. When a broad brief is presented to

a team there is always a risk that the team will

end up with old solutions following fixations from

past experience and not recognized as fixations.

This could consequently be avoided by

providing a narrow brief with clear directions for

the team.

Hypothesis 3. Level of ambiguity: Storyboard

briefs are more ambiguous than written briefs.

This hypothesis needs more research in order

to be understood. And, as formulated here it is

not proven…

Page 20: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 16

From Wikström 4.3.2 Study G 4.4.1:

General: This experiment involved two different methods to frame a problem, storyboarding brief and written brief. The methods were compared in an

experiment where three hypotheses were tested with two different setups, one with teams doing the whole workshop and one with a switch of teams

after the naming phase in order to evaluate the interpretation of the briefs.

Hypothesis 1, regarding meaning and function, is not confirmed since some of the briefs included both meaning and function and no distinct result

could be determined. It is an interesting finding however, that storyboarding briefs often include both meaning, i.e. why a problem occurs, and

function, i.e. how the problem can be solved. This could be expressed as a situation, i.e. what is happening when the problem occurs. This allows for

different possibilities and outcomes of the next phases in the design process. This fact actually forces a focus on meaning when framing a situation

using storyboarding.

Hypothesis 2, regarding narrow and broad, is considered confirmed since all storyboarding briefs were narrow in their scope while all the written briefs

except for one were broad. Storyboarding briefs are in general narrower than written briefs since the sketches in storyboarding usually describe

situations, while the focus of a written brief is on describing important events briefly in a short context. This allows for a broader scope since the root

cause of the problem is undefined.

Hypothesis 3, regarding the ambiguity of the storyboard, needs more research, but some indications of the ambiguous level of storyboards are

presented, however not enough to make a statement about the hypothesis.

Page 21: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 17

3. Comparison of two problem-framing workshops with and without

storyboarding

i. Description of workshop without storyboarding

This week-long workshop, designed in particular to encourage exploration of

divergent solutions as part of our software development process, was undertaken

in March 2013 in Sydney, Australia. It has already had quite a profound effect on

the development team. While they have not yet been able to completely integrate

the workshop activities into their regular process, the desire is there and some

changes are already in place.

One of the key messages of this workshop was the challenge to resist the strong

desire that surfaces, when presented with an apparent design problem, to resolve

it as quickly as possible. This was presented along with an encouragement to dig

deeper, to better understand the problem, and to present alternative, perhaps

contradictory, and even crazy solutions.

The underlying purpose for communicating this message was to avoid the

syndrome known as ‘Local Hill Climbing’. The following image from Sketching User

Experiences: The Workbook (Buxton et al) displays the problem clearly.

Because the software already exists, a direction has usually already been taken

regarding how certain functionality is provided. The temptation is strong to

continue in the same direction when future problems arise without considering

Page 22: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 18

whether an alternative way of providing the functionality might be significantly

superior (which may even involve backtracking initially).

In this workshop several hours of video footage from a number of clients at work

were presented to the participants. The material (around three hours of footage in

total from nine different clients) was broken down into manageable blocks for

review and analysis during an initial two-day phase. In his book Lean UX, Jeff

Gothelf notes that “Nothing is more humbling (and motivating) than seeing a user

struggle with the software you just built.” This force was at work while watching

the videos and some of the participants immediately began to design solutions

when they noticed the users experiencing difficulty. Nevertheless, everyone was

encouraged to withstand the tension of these unresolved problems and to first

spend time simply soaking in the existing user experience and trying to

understand the clients’ broader problems and greater goals.

The analysis consisted of identifying the tasks being performed by the users being

observed. Each person was instructed to write down the tasks they noticed as

quickly as possible on individual yellow sticky notes (“Enter dates”, “Double check

dates”, etc). Once the capturing of the tasks was complete the group was broken

into teams of four or five where each member brought the information that they

had noted and the results were analysed and synthesised.

Having begun with two days focussing on the client setting for inspiration, the

workshop continued over the following three days with the groups suggesting

various solutions to the design problems that had initially been observed and

summarised and finally implementing these solutions as paper prototypes which

were practically tested. The teams were encouraged to continue iteratively

towards a working prototype.

To bring alternative perspectives different exercises were included throughout the

week such as ‘Design the Box’ to help participants think about the product vision,

or the creation of ‘How Might We’ questions to encourage wider exploration of

both client problems and potential solutions.

The feedback from the workshop was generally very positive although the early

phase of capturing the written tasks on the sticky notes received the most

attention in terms of alternative suggestions for a similar exercise in future. These

suggestions were not significantly different (for example instead of capturing the

tasks on sticky notes and grouping them visually, a suggestion was made to

simply write them down individually on a single sheet of paper and then share

them to arrive at a consolidated version). Nevertheless, the existence of these

comments clearly indicated that there was room for experimentation here and

Page 23: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 19

suggested that this phase might need to be approached differently to be more

effective. Looking back at an email exchange with one of the participants shortly

after this workshop, I find that I wrote the following:

“I guess the question remains whether the sticky note exercise was worth doing

at all. I suspect that it helps direct the listening a little (since just watching the

videos alone would be pretty gruelling). It also provides a reason to get up and

move about and get the blood flowing and exchange a little while our attention

was on the subject. It did help to draw out the fundamental structure of what

needs to be supported. Using the yellow/blue sticky notes, we tried to come up

with 'scenarios' which highlighted a couple of things for me - one was the

tendency to try and be creative about what could be done for the client (all sorts

of interesting ideas but really off-track) rather than simply and boringly keeping

these in line with what we had seen the client trying to do (instead the creativity

should be directed towards supporting these scenarios) - the other one was the

tendency to think in terms of the system or a system rather than describing a

system-independent scenario. I wonder whether we would have had something to

align these scenarios with (and reveal which ones were off-course) if we had not

done the sticky note exercise, however it is possible that this could have been

captured in a different way. I am open to suggestions.”

So as well as wondering how to influence the team to naturally consider the client

perspective I see that I was also actively wondering how this part of the workshop

(which was intended to become part of the development process) could be

revised.

Page 24: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 20

ii. Description of workshop with storyboarding

This second workshop was held in Dec 2013 in Noida, India and was devised with

the intention to cover the same ground as the previous workshop with the

exception of removing the exercise of capturing written tasks and replacing it with

a storyboarding exercise aimed at framing and reframing the problem visually.

As soon as the exercise began it seemed a step too far to ask participants to

produce traditional framed storyboards so I instinctively broke the exercise down

with the intention of taking smaller steps towards a storyboarding outcome.

The participants were invited to observe recordings of clients performing tasks

using our software and visually identify elements of that context which seemed to

be important. This was encouraged by using the questions Who, What, How Many,

Where and When.

This was a significant departure from the first workshop where the focus at this

stage was more on the actions or activity of the subjects, rather than the

elements (people, locations, time frames, etc) playing a part in the story which

was the focus here.

At regular intervals, and to provide relief from the intense concentration required

when watching the recordings, participants would share their observations with

the group and were all encouraged to propose a symbol to represent each one.

These observations were consolidated and the symbols compared, discussed, and

simplified to a point that they were easy to draw by anyone and still quickly

recognisable.

This process was repeated while observing different clients performing the same

activity until the list of relevant visual elements seemed to be exhausted. At that

point the exercise shifted into a creative mode. Two teams were formed and team

members were asked to reflect on the entire client process that might include the

excerpt that we had been watching. They were invited to create a storyboard

about that, using the visual elements that had been collected during the

observation phase.

The teams taped large sheets of poster-size paper to the wall and, using the

symbols drawn on sticky notes as well as coloured markers, they prepared to tell

their stories. Each team created a visual story selecting from the elements that

had been identified and agreed, along with dialogue (speech bubbles) and arrows

(to direct the reader through the narrative). The teams then shared their stories

Page 25: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 21

with each other, talking through the story with the storyboard serving as a

support for the storyteller.

There seemed to be a lot of playful interaction during this process. Despite their

serious nature there was a light-hearted approach to the stories with the dialogue

and characters bringing drama. For example “Please make it quick. I must have

that in two minutes”. This kind of statement from a character in a story connects

at a much more emotional level than simply documenting something like ‘Clerk

waits for document’.

The teams then created a second storyboard and this time, rather than reading

their own stories, participants attempted to read and tell a story that they hadn’t

created, based on the storyboard provided by the other team. Interestingly, most

likely because of the symbolic nature of the storyboards, this was remarkably

simple to do and the stories, while not trivial, were easy to follow for anyone

familiar with the client domain.

Since the output did not conform to the typical framed storyboard format I have

begun to refer to these visual stories as ‘symbolic storyboards’.

Note that these representations should not be confused with the flowcharts

encouraged by Dan Roam for use when depicting “How”. Those are indeed

flowcharts, that is, they contain process and decision points, albeit annotated with

symbolic images and visual representations aimed at facilitating the rapid

comprehension of the material presented. These symbolic storyboards on the

other hand follow a simple narrative telling a particular story that plays out in the

client’s world.

Page 26: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 22

iii. Criteria used for comparison

It is worth noting that, as with any workshop, the facilitator plays a part in

ensuring that all participants feel safe contributing. Normal ground rules were

established in both workshops to ensure all contributions were considered as

worthwhile while at the same leaving room for spontaneity and creativity by

maintaining a certain level of flexibility.

Potential criteria for a project of this sort might include the number of ideas

produced as a kind of measure of creativity, or the value of the ideas presented,

however the focus of my curiosity was more to do with the relevance of these

ideas to the client domain. In particular, I was interested to determine whether

the ideas suggested would be more appropriate when they arose after having

described this context visually.

The other difference I was looking for, although I may not have been able to

articulate what was bothering me about the task-writing exercise at the time,

was, I now realise, in terms of physical engagement. I was wondering whether

working with visual storytelling might have an impact on how the participants

naturally participated and interacted from a physical perspective.

In retrospect three other criteria are also worth noting: the number of questions

posed about the client domain; the efficiency with which client stories could be

discussed; and the level of enjoyment, laughter and fun.

Finally, while determining whether something was being gained by introducing the

storyboarding exercise I wanted also to somehow measure whether anything was

being lost by eliminating the task-writing and analysis exercise.

Page 27: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 23

iv. Some images from the symbolic storyboarding exercise

A. Visually identifying key elements

Page 28: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 24

B. Simplifying and standardising the symbol for each element

Page 29: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 25

C. Using the visual elements to create a symbolic storyboard (dialogue adds emotion and

context)

Page 30: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 26

D. Telling the stories with gestural participation and natural enquiry

Page 31: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 27

4. Results and discussion

i. What were the significant differences between the two workshops?

There were eighteen people in the first workshop, and only five in the second

workshop, so naturally the idea output in terms of numbers was larger in the first.

Nevertheless the ideas presented by both groups followed a similar path of

refinement and sophistication upon deeper reflection. For example, beginning with

a review of a screen for entering dates which arrive on printed letters, after

successive iterations of proposing alternative solutions, both groups eventually

suggested some form of electronic interpretation of the letter to avoid the need

for data entry and its associated risks.

The workshops were designed to be as inclusive as possible with everyone from

the wider development team invited. This net caught business analysts,

developers, quality assurance testers, technical writers and managers in both

groups.

The first workshop was held in Sydney in March 2013 and the second in Delhi in

December 2013. Cultural differences were anticipated but not explicitly

encountered. Both groups responded with similar willingness, curiosity and

dedication to the workshop process. It is possible that storytelling plays a greater

role in Indian culture so this may be an influencing factor.

These were my initial observations of the storyboarding activity:

It was funny and fun, which promoted relaxed contribution and increased

concentration.

It proved to be an extremely rapid technique for telling a real world story in a

way that everyone could quickly understand and easily discuss.

Keeping the visual symbols extremely simple meant that anyone could draw

and recognise them.

Without any preparation beyond understanding the visual symbols and the

context, one team could ‘read’ the story of another team.

The picture stories fostered discussion and the thinking space was broadened

from the purely abstract (written text) to visual and gestural, naturally

increasing comprehension and creativity (by engaging different parts of the

brain).

The process quickly revealed gaps in understanding and thus identified where

further research might be required to better understand our clients’ stories.

This led to fruitful questions.

Page 32: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 28

Regarding the criteria defined previously, the following results were observed.

Note that in this business context the workshop itself was the focus rather than

the outcome of the experiment so these results should not be considered to have

been rigorously obtained. Also, at the time of conducting the first workshop I did

not know that I would eventually be drawn to this investigation so my

documentation of the experience is somewhat limited. There is nevertheless some

value to be gained from listing these observations.

Used written tasks to

explore client domain.

Used symbolic storyboarding

to explore client domain.

Contextual

relevance of ideas

Most on target*, a few way off

target. This was what sparked

the original inquiry.

All on target*.

Physical

engagement during

exercise

Despite encouragement to

stand and physically interact,

there was no natural reason to

continue this behaviour when

working in an abstract context.

Regardless of the confined space

for this workshop, physical

activity and interaction occurred

much more naturally.

Level of fun and

enjoyment

Some found this aspect of the

workshop tiring and were

inclined to behave passively.

Much more fun, laughter and

playfulness during this phase of

the workshop.

Economy of

transmission

Without any cognitive aids the

transmission of the client story

is inevitably slower.

A fairly complicated client story

can be told very economically

via the symbolic storyboard.

Questions posed

about client domain

** **

Area

comprehensively

covered

*** ***

* By ‘on target’ I mean that the idea reflects an understanding of some aspect of

the client domain and seeks to meet an explicit or implicit need. Dan M. Brown

also highlights the importance of this in his book Designing Together when he

states: “Nothing is more inspiring to me than hearing (and seeing) other people’s

Page 33: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 29

ideas. But those ideas must be relevant and appropriate to the assignment at

hand.” Wikström refers to this as narrow (on target) or broad (potentially off

target).

** Questions posed. While I think this might be a useful measure, and from

memory the storyboarding group posed more questions about the client domain,

this may also reflect this isolated team’s reduced access to client facing consulting

staff. More important to me is the value of the symbolic storyboard in revealing

where some domain knowledge is missing, so in a way it is the quality of the

questions arising that would be interesting, and how they contribute to domain

knowledge. My feeling is that more meaningful questions are likely to be posed

when using this approach. This is supported by Wikström’s findings while testing

his first hypothesis; that storyboarding always encourages consideration of

meaning and not just function whereas a written approach to problem-framing

may focus only on function.

*** Area comprehensively covered. This comparison was made by reviewing the

“How Might We” questions that had been formulated by the first workshop and

determining whether they contained any scenarios that had not been covered by

the symbolic storyboards. All of the points appeared to be included in some way

but this was determined quite subjectively. It would be worth finding a suitable

measure for comparing whether similar ground is covered. It might have been

better to produce “How Might We” questions during the second workshop and

then compare the two lists. This was not done.

ii. What were the benefits or otherwise of using storyboarding?

It is worth noting again that since I facilitated both of these workshops with no

independent researchers observing the sessions, the findings are not likely to be

neutral, but I like to think they are interesting nevertheless.

a. Contextual relevance of ideas

Regarding the relevance of the ideas proposed, this was one of the main

differences that I was looking for in the outcome of this exercise, although having

by then found Wikström’s work, I was not surprised to find that my observations

were in line with the prediction of his Hypothesis 2 from study G, that A

storyboarding brief is narrow in its scope while a written brief is broad.

This result alone is enough to suggest to me that symbolic storyboarding is worth

incorporating as a tool to explore the client domain. In business, while creativity is

to be encouraged, it is nevertheless more efficient and more likely to be effective

Page 34: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 30

from a business perspective if this creativity expresses itself within the constraints

of the client context. This is important.

A delayed effect of this was revealed more recently, months after the workshops,

by a recent ‘hackathon’ held by the development team. During a ‘hackathon’

period the developers may attempt to resolve any problem or work on any

technical issue that interests them. Those who attended the workshop which

included the symbolic storyboarding began their proposal with a problem that was

squarely situated in the clients’ context, even though this particular scenario was

not the one used in the workshop.

I was interested to see that these developers were much more inclined to start

their exploration by searching out a problem to solve that originated so clearly in

the clients’ domain, whereas those who had attended the workshop without the

storyboarding activity tended to focus on function – solving problems that they

themselves have found to be a problem or that they imagined a client might find

useful based on existing functionality.

b. Physical engagement during exercise

My impression, as the facilitator, was that the energy levels were higher when the

participants were working visually than when collecting the tasks in written form.

The level of physical participation, discussion and interaction was greater in the

symbolic storyboarding exercise. This was also suggested by the feedback. While

the group using the storyboarding approach showed unrestrained enthusiasm for

the various exercises as a whole, some members of the group whose workshop

included the task-writing exercise singled this particular exercise out for potential

modification.

In both workshops I encouraged participants to work standing up. With the task-

writing exercise the participants were arranging clouds of individual written tasks

on the wall. For the storyboarding exercise the participants were adding individual

elements to a story on the wall. Even though the written tasks, being on sticky

notes, had a certain physicality, the phrases themselves were necessarily

abstract.

When asked for feedback after the event one participant suggested changing this

particular activity: “My idea is that you take notes on normal paper, and then use

the whiteboard to organise the ideas and write them down, as a team like we did.

You can then eliminate duplicates as you go. So if three people wrote the same

idea/note you only need to write it up once on the board.” This indicates that the

Page 35: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 31

entire process of writing down the tasks was mainly cerebral and that physical

interaction was not an inherent part of the exercise.

With the symbolic storyboards on the other hand, team members were taking

each other through a story told with images, speech bubbles etc. Interacting with

the space in front of the storyboard and pointing at the visual elements while

telling the story or asking questions, occurred quite naturally. The symbolic

storyboards were depicted on poster-size sheets of paper which were big enough

to invite this gesticulation. If these had not been created in such human

proportions it is possible that the same effect might not have been observed.

In their article Action’s influence on thought: The case of gesture, Goldin-Meadow

and Beilock state: “the information conveyed in gesture is often not conveyed

anywhere in the speech that accompanies it. In this way, gesture reflects

thoughts that speakers may not explicitly know they have. Moreover, gesture

does more than reflect thought—gesture plays a role in changing thought.” This

indicates to me that ensuring an environment which enables and encourages

gestural interaction is worth pursuing.

c. Level of fun and enjoyment

It is interesting to note Wikström’s observations at this point: “One such area (for

further research) is something that has been observed during the experiments

comparing storyboarding and written documents. There seems to be much more

interaction in the teams that work with storyboarding than in the teams working

with written briefs. It is not only the fact that all team members seem to be

involved in the interaction; the level of interaction and playfulness seems to be

higher.”

This leads into the ‘fun’ aspect of the exercise which was something I had not

specifically anticipated but also observed. There was a great deal more laughter

and playful interaction in the group working together to identify the visual

symbols and symbolic storyboards.

Dan Roam touches on this when he says :“What if there was a way to more

quickly look at problems, more intuitively understand them, more confidently

address them, and more rapidly convey to others what we’ve discovered? What if

there was a way to make business problem solving more efficient, more effective,

and … perhaps even a bit more fun? There is. It’s called visual thinking...”

Page 36: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 32

d. Economy of transmission

Finally, regarding the ‘economy of transmission’, my observation was that the

client stories were transmitted quite clearly and extremely rapidly via the symbolic

storyboards. This causes me to wonder about the basis for Wikström’s Hypothesis

3 from study G, that Storyboard briefs are more ambiguous than written briefs.

Wikström notes: “Another part that is really interesting is the ambiguity of

storyboarding, which is mentioned in the discussion as a space for reframing. The

fact that storyboarding could bring space for reframing in the pre-brief activities

could bring new knowledge both to storyboarding and to the activities involved in

making a brief today.”

It is interesting that this was a hypothesis of Wikström that he identifies as “not

proven since it was more difficult to find ambiguity in these experiments”, stating

also “This hypothesis needs more research in order to be understood. And, as

formulated here it is not proven…”

Because storyboards present actual situations that naturally must make sense my

suspicion would be that, on the contrary, ambiguities and lack of clarity are more

evident when presented visually and are more likely to be questioned and

eliminated in the story-building process. As an example I invite the reader to take

a moment to imagine this scene: Flowers are being delivered to a florist.

In your mind’s eye did you see a truck or a courier, a barge or a drone? A sketch

of the scene, no matter how rudimentary, would leave less to the imagination.

This suggests to me that storyboard communication would be less ambiguous

than a written description.

Curiously, I have found that when I am discussing the use of storyboards to

describe client scenarios I have met with a similar assumption that images do not

communicate as clearly as words, and that there will necessarily be ambiguity in

stories presented visually. This is not supported by my (albeit limited) research.

Instead, the act of telling the story visually seems to ensure that gaps and

inconsistencies, which could easily be glossed over or otherwise missed in a

written description are much more apparent.

In the context of the workshop, the natural illumination brought by visual

representation helped participants identify areas where they lacked sufficient

knowledge of the client context to visually articulate a meaningful scenario.

Questions arose spontaneously regarding the client context and the approach

fostered an enquiring attitude.

Page 37: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 33

When preparing comic strips to describe particular client scenarios I have found

that same force at work. I may think I know enough to describe a situation

however when I attempt to tell the story in storyboard form, I often find that I

don’t actually know, for example, who would typically be asking such a question,

or where such information might originate from.

Perhaps the suggestion of ambiguity stems from the idea that a particular image

may not mean the same thing to two different people.

In our workshop however, because the elements used in the symbolic storyboards

had quite clear and agreed meanings, they could usually be correctly ‘read’ by

others. In fact, it is useful to note, that the one time the meaning of a symbolic

storyboard needed clarification was when a group had decided to use a discarded

symbol within the story, instead of the established symbol. Nevertheless, once

this was clarified then viewers were able to rapidly accommodate the alternative

symbol (even though this is presumably cognitively less efficient).

Colin Ware touches on the efficiency gained by using agreed symbols in his book

Visual Thinking: for Design: “One way that visual displays support cognition is by

providing aids to memory. Small images, symbols, and patterns can provide

proxies for concepts. When these proxies are fixated, the corresponding concepts

become activated in the brain. This kind of visually triggered activation can often

be much faster than retrieval of the same concept from internal long-term

memory without such aids. When an external concept proxy is available, access to

it is made by means of eye movements which typically take approximately one-

tenth of a second. Once the proxy is fixated, a corresponding concept is activated

Page 38: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 34

within less than two-tenths of a second. It is possible to place upwards of thirty

concept proxies in the form of images, symbols, or patterns on a screen providing

a very quickly accessible concept buffer. Compare this to the fact that we can hold

only approximately three concept chunks in visual or verbal working memory at a

time. There is a major limitation to this use of external proxies—it only works

when there are learned associations between the visual symbols, images, or

patterns and particular concepts.”

Another important observation was the way in which the participants quickly

began to combine symbols into meaningful new elements. As an example, a

symbol had been defined for a Patent or Trademark Office (PTO) and another for

an attorney firm. A symbol had also been defined for a letter from the PTO which

included the PTO symbol. One team created a new symbol for a letter from the

attorney by simply substituting the attorney firm symbol for the PTO symbol on

the letter. This could be read and understood effortlessly. In fact the reader is

most likely thinking ‘Of course how obvious.’ because this finding almost goes

without saying. This in itself is interesting and tells us something about the way

we adopt meaningful symbols, which is, extremely easily.

So, while it is evident that new symbols can be quickly accommodated, in order to

further reduce this cognitive load and ensure an efficient use of symbols, I’m

inclined to begin assembling a standard vocabulary of icons for symbolic

storyboarding in our particular context, arising out of the workshops and which

may be used in future workshops with developers and clients alike, so that a

particular entity or element (for example an examiner) is always represented by a

particular symbol in any symbolic storyboard. This should increase the rapidity

with which the symbolic storyboards are able to be interpreted, and reduce the

risk of ambiguity (which of course is always present in any form of

communication).

Interestingly, this seems to be a similar path taken by Otto Neurath who began in

1927 to create an international picture language based on ‘ISOTYPE’s.

(International System Of Typographic Education). These recognisable symbols

were intended for use in general education to increase the efficiency and

effectiveness of communication and to ensure that information was more freely

available and widely understood.

Page 39: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 35

In the book International Picture Language, Neurath states: “The first step in

ISOTYPE is the development of easily understood and easily remembered

symbols. The next step is to combine these symbolic elements. For example,

there is a symbol for shoe and another for factory. By joining these two symbols

to make a new one, we can talk about a factory in which shoes are made.” Picture

17 from the book demonstrates this.

Page 40: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 36

5. Conclusion

Gordon MacKenzie’s book Orbiting the Giant Hairball holds a very important clue

about creativity, which is worth remembering when considering the

implementation of any process for encouraging innovation. In it the author tells of

how he ran a successful creative workshop where he felt that he was feeling his

way or ‘groping’ as if blind. Later he set out to repeat the experience with a

different set of people but this time he almost knew what would happen and what

the outcomes might be. The workshop was not successful to the same extent.

If there is no longer room for everyone (including the facilitator) to be surprised

by what happens next or what is thought of next, then the ‘groping’ is no longer

occurring and the space for innovative creativity is reduced. Any structure erected

to support creative thinking must always be considered in this light. That is, it is

not the structure itself that holds the answer; rather its value is the extent to

which it supports creative behaviour within a given context.

Bearing that in mind I think we should introduce symbolic storyboarding into our

software development process as early as possible in the exploration of our

specific client domain. My investigations suggest that this will provide, in the most

efficient way possible, an increased awareness and better understanding of the

client perspective. In particular, by using the symbolic storyboard approach we

will be forcing ourselves to explore meaning in the client context, which could

potentially stimulate breakthrough solutions.

Further, due to the energising aspect of the approach, and the additional

communication layers added by visual and gestural communication, including this

as a standard part of our process should also naturally increase the level of

implication and motivation of the participants.

Page 41: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 37

6. Further observations/reflections/questions

i. What effect would it have to confine the storyboard into frames?

Clearly, the symbolic storyboards presented here do not precisely reflect the

storyboarding that Wikström has been experimenting with, diverging mainly in

that the stories explored are not confined to the storyboard frame. Further

research could be performed to determine whether confining these symbolic

storyboards into the traditional, framed, storyboard format would add to or

detract from the process at this early stage of exploration.

My expectation of a storyboard is that it will include images (representational by

nature), dialogue (speech bubbles), a sense of time, and economically used

captions (e.g. Later that day …). I have not extensively analysed the stories that

were proposed by the teams but my feeling is that these elements were generally

present. Nevertheless my original plan was to encourage the use of the classic

storyboard format.

The symbolic storyboards came about naturally in the context of exploring the

client domain visually with the intention of creating framed storyboards, and yet,

having seen the possibilities for creative exploration and gestural interaction

encouraged by these symbolic storyboards, I would now be reluctant to relinquish

this activity. The open-endedness, rawness and physical size of the symbolic

storyboards invite discussion and questioning, perhaps allowing a different story

to emerge. This seems to situate the activity very much in the reflective story-

making phase.

If I have the opportunity to run another workshop, I would perhaps try a further

step where the participants use what they have learned in the symbolic

storytelling exercise to create a framed storyboard format which captures,

contains and communicates a specific problem. Clearly, the classic storyboard

format seems to be extremely effective for this.

ii. Would it still be beneficial to do the written tasks?

In his text Wikström refers to Schön discussing the trade-off between rigour and

relevance. In retrospect I realise that my reluctance to eliminate the text based

exercise was perhaps because of a perceived potential loss of rigour where details

of certain tasks might be overlooked. This was not tracked in detail so it remains

undetermined however I now consider the gain in relevance (and energy) justifies

this potential trade-off.

Page 42: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 38

One option could be to reinsert the phrase-based, verbally recorded, task

gathering exercise once the storyboarding exercise is complete however I am not

particularly inclined to do this. I like to think that the greater empathy gained by

the person having explored a client domain using storyboarding would provide the

motivation to return to the original research looking for the necessary details.

iii. What hurdles might need to be overcome for storyboarding to become a natural part

of the development process?

While exploring this area of storytelling and visual thinking in particular, I have

found that there is a great deal of general agreement regarding its value. Evident

also though, at least in our firm and in our clients’ businesses, is that text-based

approaches to thinking and communication are deep-rooted.

An important transition will need to take place before we will be able to

methodically and habitually adopt visual thinking methods. Behavioural change is

unlikely to occur unless a new approach is systematically introduced. Some of us,

particularly those who may have experienced a more text-based education, and

for whom drawing and sketching may feel awkward, will perhaps need specialised

training in this area to somehow rewire long established habits.

In my own case, while my colleagues took minimal interest in the fact that I was

drawing at work, I was surprised to discover that I found it difficult to give myself

permission to fully engage in this activity, despite the fact that I was simply

analysing, interpreting and documenting user research output using new media,

which of course is perfectly valid.

Tellingly, the comprehensive catalogue of office supplies that we use for ordering

stationery does not include any blank notebooks for drawing or sketching. Most

‘business’ notebooks are either lined or squared. This suggests to me that a

similar culture reigns in many businesses today.

There is, on the other hand, an almost bewildering array of ‘sticky notes’ which

could indicate increased use of these in the business environment, perhaps to

collect and group ideas. Recently I have been paying attention to photos of people

working with these sticky notes (in design workshops, for customer journey

mapping, etc - there are lots of examples online) and, with few exceptions as far

as I can tell, these notes typically contain words …

Page 43: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 39

7. Bibliography

i. Books

Boje, D. M., Storytelling Organizations, Sage, 2008

Brown, Dan M., Designing Together: The collaboration and conflict management

handbook for creative professionals, Pearson Education, 2013

Brown, Tim, Change by Design, Harper Collins, 2009

Buxton, Bill, Greenberg, Saul, Carpendale, Sheelagh, et al, Sketching User

Experiences: The workbook, Morgan Kaufmann, 2011

Cheng, Kevin, See What I Mean: How to Use Comics to Communicate Ideas,

Rosenfeld Media, 2012

Cialdini, Robert B., Influence, HarperCollins, 1974/2009

Gothelf, Jeff, Lean UX: Applying Lean Principles to Improve User Experience,

O'Reilly Media, 2014

MacKenzie, Gordon, Orbiting the Giant Hairball: A Corporate Fool's Guide to

Surviving with Grace, Viking Adult, 1998

Montague, Ty, True Story: How to Combine Story and Action to Transform Your

Business, Harvard Business Review Press, 2013

Neurath, Otto, International Picture Language, Kegan Paul 1936

Quesenbery, Whitney, Brooks, Kevin, Storytelling for User Experience, Rosenfeld

Media, 2011

Roam, Dan, The back of the napkin, Portfolio, 2009

Ware, Colin, Visual Thinking: for Design, Morgan Kaufmann, 2008

ii. Academic Articles

Garud, R., Kumaraswamy, A. and Karnøe, P., Path Dependence or Path Creation?,

Journal of Management Studies (47), 2010

Goldin-Meadow, S., & Beilock, S., Action’s influence on thought: The case of

gesture, Perspectives on Psychological Science (5), 2010

Norman, D. A. & Verganti, R.. Incremental and radical innovation: Design

research versus technology and meaning change,. Design Issues (30), 2014

Wikström, A., Storyboarding – Framing and Reframing Opportunities in the Front-

Front end of Innovation, Doctoral Thesis, Mälardalen University, 2013

Page 44: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 40

iii. Web references

Molnar, Daniela, Narrative Image: The How and Why of Visual Storytelling, 2011

http://www.slideshare.net/DanielaMolnar/narrative-image-the-how-and-why-of-

visual-storytelling

O'Sullivan, Joseph & Evans, Rachel, Conserve Code: Storyboard Experiences with

Customers First, 2011

http://www.slideshare.net/IntuitInc/conserve-code-storyboard-experiences-with-

customers-first

Crothers, Ben, Using Storyboards and Sentiment Charts to Quantify Customer

Experience, 2011

http://uxmatters.com/mt/archives/2011/11/using-storyboards-and-sentiment-

charts-to-quantify-customer-experience.php

Crothers, Ben, The Power of Storyboarding, 2011

http://digitaleskimo.net/blog/2011/10/24/the-power-of-storyboarding

8. Appendix

i. Research Questions - Wikström, Anders, Storyboarding – Framing and Reframing

Opportunities in the Front-Front end of Innovation, 2013

RQ1: How does design thinking, visual thinking and narrative affect the front-front end of

innovation?

RQ1.1 How does design thinking affect the specific activities involved in innovating?

RQ1.2 How does visual thinking affect the front-front end of innovation?

RQ1.3 How does narrative affect the front-front end of innovation?

RQ2: How can innovation management benefit from storyboarding at the front-front end of the

innovation processes?

RQ2.1: What is the role of storyboarding at the front-front end of innovation?

RQ2.2: What is the difference between using storyboarding and written documents to

define a brief?

(continued overleaf)

Page 45: Should our software development process begin with storyboarding?

Anna van der Aa – Mastère spécialisé Innovation by Design – ENSCI–Les Ateliers – May 2014 – p 41

(continued from previous page)

Research Questions - Wikström, Anders, Storyboarding – Framing and Reframing

Opportunities in the Front-Front end of Innovation, 2013

RQ1

Discussing the sub-questions above paves the way for the answer to the main question.

Exploring how design thinking, visual thinking and narrative affect the front-front end of

innovation I have developed knowledge that design thinking, visual thinking and narrative

support reflection-in-action since they are used as different ways of sketching how to

understand a situation. The reflection-in-action is argued to be an important part of the front-

front end of innovation since it frames how professionals think in action. As discussed earlier,

the situation is explored with a human centredness that brings meaning; visual thinking

focuses on exploration and externalizes thoughts and ideas so that they are accessible to

other people involved in the process, and the narrative forces the team to pick and explore a

situation, and since stories are often emotional, humans involved in these situations become

central.

RQ2

First we conclude that storyboarding may enable a reflection on both meaning and function in

framing the problem. This could be useful since most briefs have a focus on function and

support a problem-solving approach even though there is a need for an approach more aimed

at problem finding (design thinking), bringing a human-centred design into the brief, and

therefore how humans give meaning to things.

Second, when a clear statement about a strategic direction is sought, storyboarding can be

helpful since it frames a narrow area within the area of interest. This allows for reframing the

situation and still having a focus within the area of interest. This supports innovation managers

in their leadership by providing space for reframing but still a clear pathway to follow. A written

brief describing a broad area may cause the team to pursue paths that are fixations from

earlier experience or knowledge. Instead, using storyboarding with a narrow focus guides the

team in a direction where hidden fixations are not attained.

Third, if management needs creativity and idea generation in order to stimulate new ideas or

thought that can lead to new directions in the brief, storyboarding supports this by

modularizing the situation and opening up gaps in the story. Such gaps activate the narrator in

us and start a process searching to close the story. This search triggers surprises in the

reflection of a situation and are deeply connected with the reflective practice.

Updated: 14 April 2014