A friend just sent me a great video about Game-Storming i.e. brainstorming using games.

I highly recommend the book it mentions: Gamestorming: A playbook for innovators, rulebreakers and changemakers. I have had some great results using techniques from this book in workshops on a wide variety of topics. (There is also a lot of academic literature about these techniques by Eva Brandt and an article on Boxes and Arrows.)

As the video states these techniques are being used by both people in business to help business solve problems and thinking differently as well as those using these techniqies for ‘future workshops‘ for designing a more sustainable future and  making the world a better place!

Interestingly, I listened to a fantastic podcast yesterday at This Digital Life where Peter Merholz and Michael Dila were talking about ‘design thinking’. One of the points that emerged in this podcast is that the term ‘design thinking’ seems to be an umbrella turned which is used within different contexts:

1. How can we think differently and more creatively within business?

2. How we can use design to help effect positive and sustainable change in the world?

These are pretty different domains but gamestorming can definately be used in both contexts.

The hosts of the podcast  also raised another point about the creative class and how we can create a modern and virtual rotary club so that creative class memebers canlend their creative skills to assist with designing a better future. LOVE the idea. Surely there is a possibility in this uber networked world of ours.

Go check the podcast out…lots of great food for thought!

I love this video….so cute and really captures what UX design is about.


Last year I undertook a compulsory unit at uni in qualitative research methodology.It got me thinking about the research we do to inform the design of applications we develop and the value of using a framework for research.

I learned about how we all bring assumptions to our research as a consequence of our perspectives and how no qualitative research can never ever be truly objective, particularly social research.

When doing research it is vital to be aware of your theoretical assumptions and to design a study that enables analysis of associated factors.

Considering your assumptions

For my assignment in this subject, I undertook a pilot research study connected with my work. My research question was a case study which looked at ‘How can we improve the documentation system for the specification of online projects within a commercial context?’ As part of this research the consideration of a knowledge sharing system of sorts, I first needed to consider ‘what is knowledge?’. My research method and analysis would need to support my answer to this question.

+ Is knowledge something that is like an object? i.e. external to and independent from individuals, that can be passed from one person to another?

+ Is knowledge something that resides within the minds of individuals? i.e. something embedded within people whereby thinking transforms information into knowledge, where knowledge involves the sharing of information to yield knowledge.

+ Is knowledge something that is contextually and socially constructed? i.e. knowledge is socially and contextually constructed, whereby knowledge is embedded within a community rather that within individuals.

I favour the 3rd perspective ….and indeed I would argue too that technology design (as within web and mobile devices) these days needs to consider both social and contextual factors.

This study also necessitated thinking about assumptions about collaboration and the role of artifacts to facilitate work and share knowledge. There is some really interesting literature about artifacts as ‘boundary objects’ (Star SL & Griesemer JR (1989)), i.e. objects that communicate knowledge across domains.

With my assumptions in mind I decided to use the meta-theoretical lens of Activity Theory to guide my research and have since decided that Activity Theory can provide a very useful framework to do design research within design for computer mediated activities and Service Design.

Activity Theory

Activity Theory takes ‘activities’ as it’s main unit of analysis taking into account the larger social and contextual systems that activities occur in. Unlike related frameworks of ‘task analysis‘ which does not consider people’s innate knowledge required of users and ‘user modeling‘ which doesn’t take context into account.

Activity Theory acknowledges the relationship between activities and their broader social and physical contexts, through itʼs consideration of activities within the context of a broader activity system comprised of other actors, mediating artifacts, social rules, division of labour, as well as other related activity systems.

It was  written about by Engestorm (in Perspectives on Activity Theory in 1999) and later applied to the design and development of IT systems by Kaptelinin and Nardi in 2006 (in their book Acting with Technology.

Activity Theory has two underlying assumptions;
1) that human cognition emerges and exists within context of an individuals interactions with the world and can only be understood in terms of these interactions or activities,

2) activity is culturally and socially determined. It focuses on the interaction between consciousness and human activity within particular activity systems or contexts.
Below you can see a model by Engestrom and some descriptions explaining this model.

Node Description
Mediating artefacts A tool that mediates the relationship between the subject and the object, which caries the history of the relationship. It can refer to a plan, an idea, a sketch or a theory. An object created by a subject becomes a mediating artifact for another actor within the activity system.
Objects In order to reach an outcome it is necessary to produce certain objects (e.g. experiences, knowledge, and physical products); they connect a subjectsʼ actions to the collective activity; something that can be shared for manipulation which can be tangible or intangible, for example, physical objects (e.g. products), soft objects (e.g. computer programs), conceptual objects (e.g. theories or models). The transformation of an object is the motive of the activity.
Social Rules Social rules which effect the activity and are imposed by the other actors including the larger organisational and professional communities.
Other Actors Involved Other actors, often called communities refers to other actors that mediate the activity. Often subjectsʼ are members of multiple communities within the organisation of which have influence on their work.
Division of Labour Activities usually involve a division of labour which are often negotiated between actors. As (Suchman 1983) notes that the actual division of labour at work often differs from those prescribed by the organisational structure .

For the interviews I did I asked questions relating to these nodes and noticed that I was able to get a holistic view of the system in question from my various respondents. I was able to use this model to see emerging patterns and felt that I got a very thorough and well rounded understanding of the state of play as well as the different needs and motivations of my respondents. I found it a very valuable tool to help guide my research and analysis.

OK….so how is all this theoretical academic stuff to UX?

These days IT systems never function within a bubble. Particularly with the fact that many people access IT systems in multiple contexts using multiple devices. For example mobile applications usually need to be divided for fragmented attention, they need to be able to picked up and put down at any given moment, and they are often used in social situations, and these devices also often “socialise” with other devices too! Perhaps we need to think more about the dimensions Activity Theory posits? How do social factors influence the contexts of your products use? It’s not really about the relationship between a “user” and a “system” now really is it?

Nardi maintains that “activity cannot be understood without understanding the role of artifacts in everyday existence, especially the way that artifacts are integrated into social practice” (Nardi, 1996, p.14). Activity Theory provides a framework to do research to inform the design of new IT systems whereby by taking the perspective of different actors within the system, a subjects’ view can compliment a systems’ view….. yielding a more detailed picture of the different contexts and actors that you are designing for.

It is in this way, Activity Theory offers a complimentary theoretical framework to consider computer supported activities and HCI research.


Engestrom, Y. 1999, Perspectives on Activity Theory, Cambridge     University Press, Cambridge, UK.

Kaptelinin, V., Nardi, B. 2006, Acting with Technology: Activity Theory and Interaction     Design, MIT Press, London, England.

Kutti, K. 1996, “Activity Theory as a potential framework for Human-Computer-Interaction     Research” in Nardi, B. (ed) 1996, Context and Consciousness: Activity Theory and     Human Computer Interaction, MIT Press, London, England, pp 16-44.

Nardi, B. (ed.) 1996, Context and Consciousness: Activity Theory and Human Computer Interaction, MIT Press, London, England.

Starr, S.L. & Griesemer, J.R. 1989,’Institutional Ecology,‘Translations’ and Boundary     Objects: Amateurs and Professionals’ in Berkeley’s Museum of Vertebrate Zoology,     1907-39’, Social Studies of Science, vol. 19, pp. 387-420.

Suchman, L., 1983, “Office procedure as practical action: Models of work and system     design.”, ACM Transactions on Office Information Systems, vol. 1, no. 4, pp     320-328.

What are they?

Design principles (also called experience attributes) describe the experience core values of a product or a service. They can be visually oriented objectives that describe the personality the product should have.

They should be written in a short and memorable way. As a designer you should know them by heart while doing a project. Good design principles are cross-feature but specific. Therefore we should always try harder than ‘Easy-to-use’. Design principles are non-conflicting.

They define and communicate the key characteristics of the product to a wide variety of stakeholders including clients, colleagues, and team members. Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole. They provide a consistent vision of the project for the project team.

They should be defined and explored concurrently with the requirements gathering/scope definitions process.

These principles should accompany requirements definition activities to help guide the solutions and concepts.

They establish criteria for success for the project.

What they should be

  • Based on design research
  • Short
  • Memorable
  • Cross-feature
  • Specific ‘not easy-to-use’
  • Differentiators taken together
  • Non-conflicting

Some examples

Google calendar’s design principles

  1. Fast, visually appealing and joyous to use
  2. Drop dead simple to get information into the calendar
  3. More than boxes on a screen (reminder, invitations, etc.
  4. Easy to share so you can see your whole life in one place.

Facebook’s design principles:

  • Universal: our design needs to work for everyone, every culture, every language, every device, every stage of life.
  • Human: our voice and visual style stay in the background, behind people’s voices, people’s faces, and people’s expression.
  • Clean: our visual style is clean and understated.
  • Consistent: reduce, reuse, don’t redesign.
  • Useful: meant for repeated daily use
  • Fast: faster experiences are more efficient and feel more effortless.
  • Transparent: we are clear and up front about what’s happening and why.

Why should we use them?

They help focus decisions and get everyone on the same page.

Used to determine what concept we move forward with.

To assist us in creating a consistent and purposeful experience for our customers.

Like specifications, they are the explicit goals that a project must achieve in order to be successful.

How do we define them?

Design principles should combine the structured findings of research with the best ideas of ideation.

They should succinctly communicate what we are trying to achieve.

Start by gathering all available research. Ask your project manager for any existing research as the marketing team often research products before they get to online.

Determine if we have time/budget to get some research done.

Some research questions could include:

  • What is the existing offering like for our customers?
  • What are our competor’s offerings like?
  • How can we improve/design our offering better?
  • What frustrations do customers have in relation to this product or service?
  • Have they been delighted before by similar services/offerings? How? Why?

An ideation session can also help inform the definition of design principles as can undertaking a competitor review.

A workshop

A Simple Recipe for Design Principles (from Leah Buley)

Set aside an hour or two to work in a small group. First, brainstorm about the personality you want for your product. Try completing these sentences:

n If our product was a person, it would be … n If our product was a place, it would be … n If our product was a neighborhood, it would be … n If our product was food, it would be …

Look for examples of people, physical spaces, or other things that describe your product’s personality.

Second, after brainstorming these ideas, discuss them. Someone should be scribing, listening closely to important personality traits or characteristics. They’ll be writing down things such as “dependable,” “busy,” “fast,” “exotic,” “safe,” and so on.

Finally, with the ideas that emerge, craft five to seven memorable statements of what the experience of using your product should be. Tivo (see the main article) calls them “design mantras” because they’re short, simple, and evocative.

Further Reading

Developing Design Principles by Luke Wroblewski

Ubiquitous computing workshop mobile user experience design principles by Rachel Henman (looks at a process for defining design principles for mobile devices)

Making research actionable: an introduction to design criteria, by Sarah B Nelson, Adaptive Path

Report from Avenue Razorfish illustrating the value of well designed and executed digital experiences.

Experience is the brand!

I have been attending PDC 2010 the last few days i.e. a conference about participatory design in Sydney.

It has been very interesting so far…both the lectures as well as the hall way conversations between a well represented international audience.

I wanted to post about a workshop I did about innovative participatory design practices held by Peter Dalsgaard and Kim Halskov from Aarhus University in Denmark.

Within this workshop, we did a design challenge using  a method they call Inspiration Cards workshops. (A PDF on their method is available).

These workshops are participatory design workshops whereby a group of designers, potential users and subject matter experts can get together to brainstorm design ideas. In these workshops a problem is first identified, for example in the example workshop we did; how can we bring the feeling of the city of Sydney to the interior of a hotel?

Subject/domain cards are first researched and then created and provided to participants. These are tangible cards like business cards with images on them. These cards represented three areas: domain knowledge, locations /contexts for the design solutions and possible technologies.

In this example workshop we were provided with some pictures of the sites of Syndney, including the Botanic Gardens, Sydney aquarium, Opera House etc.

The next set of cards were of hotel spaces eg, restaurant, lobby, hallway, lift.

The third set of cards were “technology cards”. First corresponding videos were shown of mainly interactive art to show some possibilities for technology which corresponded to these cards. For example, the drum head by an interactive artist Murat n Konar:

http://www.muratnkonar.com/id/drumhead/ was displayed as a springboard for ideas about interactive technology.

Participants were then asked to create solutions to the design challenge. Two groups competed during a fixed time period to create pressure.

It was really fun and we came u with some cool ideas… the feasibility of which was debatable but cool ideas nonetheless.

Meet Bar Mate…

Bar Mate hangs out in the bar. When you sit down it says “gday mate!”

You can change it’s avatar by shaking it.

It will give you suggestions of things to do in the city.

If you like what it tells you, you hug it or pat it and if not you slap it.

It uses an algorithm which acts as a recommendation engine  using related slap so hug data – so it should be able to give you suggestions about things you might like to do in the city.

So that was one idea…not so serious!

Kim and Peter  hypothesised that participatory design workshops have the following key elements some of which they have discussed in their previous academic papers:

+ convergence/divergence

+ tradition/transcendence

+ sources of inspiration

+ degree of structure

+ performance/enactment

+ creation/crafting

+ authenticity/fiction

+ simulation/absraction

+ roles/status

+ money

If you are academically inclined check out their work on PD innovation methods and the PDF about these types of workshops.

Using Scenarios


Some thinking about scenarios….

It takes a thousand voices to tell a single story
– Native American saying, tribe unknown

A scenario is a description of a persona using a product to achieve a goal, they describe an instance of use…in context.

Scenarios are usually narratives that tell a story describing one or more tasks in a specific environmental situation.

For the design of services and systems we can use scenarios to understand and communicate what activities our system needs to support.

Scenarios are flexible and can become more detailed throughout the project life-cycle. They should focus on the activities people do and the context in which they do them. They differ from use cases in that they focus on specific situations and capture the diversity between these. Your scenarios should illustrate all of the situations in which people visiting your site/ application will experience.

They help focus design efforts on the user’s requirements, which are distinct from technical or business requirements. They are also particularly good for discussing requirements with stakeholders who do not have any technical background.

Scenarios are the plot and personas the characters, and they can stage user actions with a future artifact.

The schema below illustrates the things that should be considered when writing scenarios.

Why Use Them

There are a number of reasons that scenarios are useful for experience design.

  • They can provide a vehicle for communication as well as a mechanism to explore design solutions.
  • They help mediate the thinking and communication required in design.
  • They are concrete yet flexible enough to change and morph in detail as the project progresses.
  • They help us understand the flow of experience and are tools for thinking about design (they help us reflect and reason)
  • They help us present and situate solutions
  • They help identify potential problems
  • They are easily understandable by all stakeholders as they are story-like
  • They can provide rich descriptions of use in context which can spark ideas and help inform design
  • They help determine if the design solution is appropriate
  • They can help us see social factors and help understand a users multi-channel experiences (i.e.z on and off-line_

When to use them

Scenarios can have a number of iterations and be utilised in a number of ways throughout the project life-cycle.

  • They can be used in the beginning of a project to help flesh out requirements.
  • They can be used as tools to explore design solutions.
  • They can be used to validate designs and reveal design assumptions.
  • They can be used to hang specifications and wire-frames off within documentation.
  • They can be used by testers to test the final designs.
  • They can be used for competitor analysis whereby a scenario can be used to compare a variety of sites to each other.

Before you begin

To write a scenario, you need a basic understanding of the tasks to be supported by the system. You also need to have an understanding of the users and the context of use. Scenarios can be derived from data gathered during contextual enquiry activities. If you do not have access to such data, you can write scenarios based on prior knowledge or even ‘best guess’, provided the scenarios will be subject to review by users prior to being used as a basis for making design decisions.

To write a scenario, describe in simple language the interaction that needs to take place. It is important to avoid references to technology, except where the technology represents a design constraint that must be acknowledged. Include references to all relevant aspects (including cultural and attitudinal factors) of the interaction, even where they are outside the current scope of the technology.

For example, the fact that Sally is continually interrupted by telephone calls may be just as relevant as the software platform she uses. These types of details should be considered during the design.

After you have written a scenario, review it and remove any unwarranted references to systems or technologies. For example, the statement ‘the customer identifies herself’ is appropriate, whereas ‘the customer types her 4-digit PIN’ is not (unless the PIN is a non-negotiable system constraint). You should also have the scenario reviewed by users to ensure that it is representative of the real world. (NB this comes from a really good book on UCD by Kim Goodwin: Designing for the Digital Age)

Evolving Scenarios

Scenarios are a great artifact which can evolve over time.

Below is a schema adapted from Pruitt and Adlin (in the Persona Life-cyle) showing how they can evolve over time.

This schema shows how scenarios can evolve and be both prescriptive and evocative and can be used at different stages of the design life-cycle.

Understanding context

Understanding a users context is central to scenario definition. The following should be considered for each persona

  1. Goals: What is the user trying to accomplish? How do the user’s actions fit into the objectives of the organization?
  2. Process: What are the steps the user will follow? How does information flow from one step to the next? What are the various roles (such as creator, contributor, editor, or approver) that are involved?
  3. Inputs & Outputs: What materials and information will the user need to successfully use the interface? What will they need from the interface to continue with their overarching goals?
  4. Experience: What similar things has the user done in their past? How has the organization survived without this design in the past?
  5. Constraints: What physical, temporal, or financial constraints are likely to impose themselves on the user’s work?
  6. Physical Environment: How much room does the user have to work? What materials on their desk? What access do they have to necessary information (such as user manuals)? What is taped to their monitor?
  7. Tools In use: What hardware and software does the user currently use?
  8. Relationships: What are the interconnections between the primary user and other people who are affected by the tool?

SRC: [Jared Spool|http://www.uie.com/articles/putting_context_into_context/]

Related Reading

Presentation: Building and using personas and scenarios

The role of personas in user centered design presentation


Kim Goodwin: Designing for the Digital Age)

Pruitt and Adlin: The Persona Life-cyle

I spent some time contracting this year at a large organisation as part of an internal experience architecture team. One of my tasks was to operationalise usability testing within the online team who were responsible for the design and development of both online and mobile sites and apps.

In the past I have done a fair amount of usability consultancy for large organisations as an external consultant. Ahhh the joy of being a consultant, where the fact that clients are paying a high fee for your services makes your work seem valuable.

Selling in and implementing usability testing in this context (as a “free” internal service) was an interesting experience and I thought I would share some of my learnings.

1. Naming the initiative

When I started this initiative I realised that some education was required. I presented an approach to the heads of online (experience architecture, development and creative) which went fairly well however a curious thing occurred afterwards whereby I got a meeting request from the test lead (part of the development team) requesting involvement in my ‘testing’ process. It seemed that the term ‘usability testing’ seemed to suggest an association with UAT (user acceptance testing). So we changed the name.

Learning 1: Use the term ‘user review’ instead of ‘usability testing’

2. The importance of framing the research

My first session involved one on one sessions with users testing a site on a staging server. Parts of the business were very keen to launch this version, whilst others considered it still in need of substantial front-end fixes before launch. Irrespective of ones opinion, the site did have some bugs, the severity of which was debatable.

When presenting my findings, I realised that some meeting participants saw this ‘user review’ exercise as an exercise to catalogue bugs rather than a way of gaining information about how actual customers interacted with the site. Instead of wire-frames and recommendations for improvements, they seemed to expect a catalogue of existing bugs. From this first presentation I learned the importance of a bit of educational material at the beginning of the presentation and the importance of framing the objectives of the research.

Learning 2: Focus on user perception and the users’ journey on a site rather than just cataloguing bugs. Video is a great way to illustrate usability issues and illustrate customer delight or confusion.

3. Reporting Language

The aim of these ‘user reviews’ is ultimately to help improve the experience of customers with online and mobile products. Often this involves the unlocking of additional funds. With this in mind, I realised that it was important to communicate my findings using business terminology with the projects’ associated KPI’s in mind.

For executives and business people, numbers have power and numbers with $ signs even more power. Being able to set up tests from which I could benchmark the performance of existing properties compared to the performance of new ones was also valuable to frame the findings and quantify possible improvements. Business people usually value “conversion” more than the provision of “superior customer experiences” (I confess I have found that unfortunately not everyone yet gets the relationship between the two!). For example, after some remote testing I found that with a proposed IA that 40% of people were more able to find support pages about a common problem using the proposed IA than they did using the current sites IA. Speaking to the call centre manager, I supplemented my report with statistics as to what % of calls were currently made in relation to this matter. Through relaying this information in my report in a concise and easily digestible format manner  the improvements were made more tangible and relevant.


Additionally, as I am sure you are aware, execs are really busy and don’t have time to read long winded reports. Particularly reports that they have not specifically commissioned on topics that they may not yet be 100% convinced about. Making your reports scannable with graphs highlighting efficiencies, savings and potential profits ratifies both the importance of fixing usability issues as well as your work.

Lesson 3: Pictures speak a 1000 words…but projected percentages speak 1000 pictures.


In Summary: Complimenting your usability research work with education and well considered reporting can really help businesses engage with your in-house usability initiatives.

About Co-design


Expanding upon my last post about the initiative by EU governments to encourage design driven innovation within the EU, I found some videos explaining what co-design is from UK service design agencies Think Public and Engine. This last post had many examples of this drive within UK and both these videos discuss Service Design work they have done for the UK government.

This first one from Think Public :

Interestingly, within this video after talking about Think Public’s work with the NHS someone describes the rise of ‘co-design’ in the video as the “collaboration movement”.

(NOTE: Having not lived in the UK myself….I can only quote by  English friends reaction…”It’s great that the UK government is trying to find new ways to improve their public services ‘cos they definitely need a re-think!”)

This 2nd case-study for Kent County Council by Engine looks at how co-design was used to design local government policy.

Engine helped the Kent local government find new ways to personalise services and help understand the people that they serve.

The people from Kent County Council think that design provides a structured approach for generating ideas and mentioned the value Engine provided by making things tangible, and their ability at identifying and communicating patterns between what a  broad spectrum of customers need.

I recently wrote a post with a collection of quotes about design which seem relevant here:

Herbert Simon – “changing existing situations to preferred ones”

Donald Schon – “a dynamic knowing process”

Buchanan, Richard – “the subject matter of design is potentially universal in scope”

Check out the videos:

Another video about the Kent County Council and Engine collaboration.