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

Advertisements

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

30Nov10

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

http://www.uie.com/articles/putting_context_into_context/

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

21Nov10

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.


I recently spotted a report done by the commissions of the European communities called “Design as a driver of user-centered innovation

“The working hypothesis of this document is that design is a driver and tool for user-centred and sustainable innovation and differentiation, complementary to technological R&D, and that increased use of design could increase European competitiveness. The objective of the document is to provide an analysis on the importance and potential of design as a tool for innovation, on the rationale for making design an integral part of European innovation policy, and to provide a basis for a public consultation to take place in 2009, the European Year of Creativity and Innovation. The results of the public consultation will feed into the new European innovation plan.”

In alignment with this initiative, in October the European Commission set up the Innovation Union which will use public funding to help stimulate private sector  innovation within Europe. There is a video about this on their site and a  press release of the launch.

Interestingly as well, the UK Design Council seems to have a similar agenda.

Their site outlines it’s aim:

Helping Britain use design to build a stronger economy and improve everyday life
We are a centre of new thinking and insight into new ways to do business. Our work shows how design can tackle big challengesand improve everyday life. We run practical demonstrations and support programmes for private industry and the public sector. And we invest in the future of UK design.

The UK Design Council too have quite a videos on their own YouTube Channel

The video entitled Design’s Role in Innovation shows some speakers who took part on their The Big Rethink conference held earlier this year. This event was held in collaboration with The Economist earlier this year.  (There is also another one scheduled for March 2011). There are illustrations of the talks from this event and audio of the presentations are available as well.

Further there is another UK government resource (Business Link) linked from the UK Design Council with resources for small and large businesses about how to become more design-led with a large section all about User Centered Design. (Other topics include sustainable design, working with designers, branding etc.)

What a great resource for businesses!