exhibit research notes on process
This is compiled from experience in creating exhibits and installations, but could apply more broadly to other interactive projects.

Define Audience

In museums, this is usually fixed, but varies with particular exhibitions

"General audience" usually means you have to design for schoolchildren up to research scientists, and include several levels of experience/information

What are their goals?

Remember projects that will be ported to other media (i.e. museum kiosk programs ported to web)

Usually there is more than one intended audience; which is most important?

Create scenarios

A useful character: your mother

Set goals

Who will be involved in goal-setting?

How will they be determined? (research, consensus, brainstorming)

Who will make decisions? (Consensus is important, but one person should have final say)

Seek an objective view of the problem space

Triangulate information from multiple sources, especially end users

Questions to ask:

What is the mission or purpose of the organization?

What are the short- and long-term goals of the project?

Who are the intended audiences?

Why will people use it?

Are the goals the right ones? (Do they solve the problem at hand?)

Are the goals well-defined?

Distill problems into single sentence bullets

Don't include solutions with problems -- there are often alternative solutions

Separate what could be done from what should be done

Most people like to set finite scope and stick to it; I do too, but inevitably end up fussing and fixing up to the deadline.

Then start on schedule and resource allocation

What can't you do? Hiring or contracting depends on needs, budget.

With tight budgets, students, artists, and universities make good partners.

Schedule

Prioritize: Identify critical or most complex elements

Clearly delegate responsibilities for components

Allocate enough time for debugging, optimization, captioning, duplication

Work backward, starting with final review/sign-off

Include reviews of critical elements

Start collecting content early

Get Organized

Make a simple web site This literally keeps everyone on the same page

There are simple ways to password-protect it

Put links to hardware, vendors, etc.

If you don't know HTML it can be text, a PDF or a Word doc that sits on a server.

Stay on track It is invaluable to have someone to keep track of deadlines and budgets.

Research

How has this topic been treated in the past, in yours or other media?

Competitive analysis

Define Content

What information must be conveyed? Where will it come from?

What functionality is needed?

Build it or buy it?

Can it be done on schedule and budget?

How much is enough? How much is too much for one project? In general, narrowly focused projects are better than broad ones.

Flow Chart

Where, when info is accessed

Begin with list, then outline, then map

Note where multiple pages/screens are

Include links forward and back

Analyze

hierarchy Distinct screens

Layers

Depth

navigation

What will be global (accessible from everywhere)?
Design

Who, what, where, when, why, how?

The functionality needs to be designed first, but design has to begin soon and work hand-in-hand with programming

Brainstorm, prototype, and iterate

Some people sketch out designs first; others mockup functionality first

Tests concepts before investing programming resources

Reasons for prototyping: Proof of concept, design exploration, or technical exploration

Breadth v. Depth

For static items, images are enough; for processes, functional mockup

Look and feel

Metaphors? Yes, they're cumbersome and not always useful, but it's important, at least, to have a high-level description that normal people can understand

  • Organizational
  • Functional
  • Visual

    How literal? Beware of users taking them too seriously

    For more on metaphors, see this article by Aaron Marcus.

    • Common info viz techniques (from Keim, 2001)
  • 2D plots & graphs
  • 3D landscapes
  • geometric transformations & projections
  • icon- or thumbnail-based displays
  • dense pixel color displays

    • Branding

    Consistency

    Layout Grid

    When to break the grid

    Engine and tool parameters

    Interaction Design

    interaction/distortion techniques (from Keim, 2001)
  • filtering
  • zooming
  • linking
  • clustering

    • Interface Design

    Where person meets system

    Storyboard

    means describing features/paths as a story, in plain language and simple imagery

    Design incrementally

    What is the minimum needed to get the info across?

    Put out frequent small releases for feedback

    Create a Design Document With above info
    Keep updated with art, screens, etc.
    Programming

    Program incrementally, keeping bug-free at every stage before moving on If there are bugs, prioritize them

    Create a functional mockup of all screens (function only: NOT designed)

    Document everything

    Keep an Art Bible with concept sketches, photos, mockups -- all labeled and dated

    Use version control and naming conventions

    Use an organized folder structure

    Even the best-run project is a work in progress, as conditions and requirements change over the development cycle. The "eXtreme Programming" (XP) movement suggests many small course corrections rather than a few major ones. As requirements, technology, and staff change, the process must be flexible enough to change course mid-stream. Core values derived from XP are:

  • Communication & feedback
  • Simplicity (of code and design)
  • Courage (to change course or experiment)
    • Links

    Scott Berkun's articles on interface design and process

    WebMonkey tutorial on information architecture.

    Article on visual exploration of large datasets

    Article on eXtreme Programming process, as related to embedded systems programming

    Kevin Walker