Recently in UX Week '07 Category

[Live blogged notes from Adaptive Path UX Week 2007. Learning Interaction Design From Everyday Objects by Bill DeRouchey]

How can we go out into the world and get inspired by the real world?

Just as artists go to museums to see how their predecessors work. As designers we are surrounded by inspiration in everyday objects. There are buttons, dials, and more everywhere. There are buttons and dashboards in our cars. Look at the defrost icons. Why are they squiggly line pointing up? Because we've seen that before.

Look at how ATMs use blinking green lights to guide you through the process. Put your card in here, get your money here, etc.

The goal is to look closely at things and see what they are doing. Look for interface elements that are hidden and think about why they are not obvious.

[Bill is showing some great examples that I can't describe]

Look at the relationship between labels and controls. Pay attention to the implicit decisions in things and weed out things that cause hesitation and interruption (unless you are putting that lag in deliberately).

Interfaces need to communicate how a thing is to be used. If things are confusing, the process is delayed.

Just as inspiration fuels design, attention fuels craft.

Get as close as possible, pay attention to the details. Look at how Blackberry overlaps number and letter keys.

Ask "why is every little thing there?"

Look at the power indicator light on your Mac. Subtle feedback is deeply important.

Looking at the back of U-haul truck we see the language of digital design seeping out into other domains. Pieces of paper say "click here" and give you a URL.

Interaction has a language. Think of a black triangle pointing to the right. It always means play. We create and curate this language through:

• Color
• Icons, Words
• Size, Shape
• Layout, Motion
• Sequence
• Sound, Feel

Why?

• Priority
• Clarity
• Purpose

Give people something to latch onto when they use your product. Communicate what you are doing clearly. Is the purpose implicit? Does the thing stay within its purpose.

Do the elements have a hierarchy? Are things grouped together?

• Size
• Color
• Zoning

Look at remote controls. Think about how grouping is used (or, more often, not). Remote controls should not have as many buttons as a laptop. This is ludicrous. Tivo solved this problem. There are fewer buttons that are grouped according to use. Tivo decided what matters most: Pause. This is a deliberate choice. It connects the device to the brand and to the function. Grouping is organized into clear zones: Select, Adjust, Control, and Pinpoint.

Think about grouping of abstract verbs in your design (learn more, read, etc.).

Look at the interface on an HP all-in-one printer. The interface lacks priority. You have to get to the labels before you can understand what the button does. The device has five Start buttons.

When people are confused they will hack the interface. They will add their own labels to the device to solve their problems.

Does the interface communicate clearly? Use action verbs to explain what people need to do.

Think about the relationship between status and label. Think about the purpose your icons serve in the interface. If they don't serve a purpose, don't use an icon.

Choose labels that mean something. What is the difference between TurboCool and ExpressChill on a refrigerator?

Consistency is very important. Look at how buttons move around on ATM and card-swiping interfaces.

Red = Bad; Green = Good. Why? Fire = Bad; Tree = Pretty. This convention just works. Pay attention to convention!

So think about the Record button. Why is this red and the power button is green? Go back to cassettes, keep going back. It seems to come from On Air lights. Recording was a warning so they used red.

Think about how a product is used in context. Use colors to signal status in context.

Pay attention to the purpose of the product. Does it stay within what is supposed to do and what it is supposed to be?

• Simplicity
• Perspective
• Restraint

Remember Fitt's Law.

Why does the microwave not remember the time? Really... Why does the microwave need to have a clock?

Don't try to be over-friendly. Use appropriate language for the situation.

For more check out historyofthebutton.com and noideasbutinthings.com

Q: What about users who want stop in a digital environment?

A: Doesn't make sense in digital.

Q: Talk more about transition from web to industrial design? Change in practice?

A: The biggest adjustment was going back to pen and paper and learning about the constraints of the medium. Sequence became more important. Sound challenges are also very interesting.

Q: Thing in ID that could help Interaction on the web?

A: Zones are a great lesson. When creating an interface, carve out the space and label with verbs. This helps build the story.

[Live blogged from Adaptive Path UX Week 2007. New Sources of Inspiration for Interaction Design by Dan Saffer]

Where does inspiration come from?

When we think about inspiration we often start by thinking "WWAD?" Apple is a rich source of inspiration. We also go to books like Designing Interfaces or a pattern library to look for how other people have solved similar problems.

But sometimes we need to get outside our space, outside our medium.

We don't need to turn to other digital products to get inspiration, we can look to the world at large as a source of inspiration. This is a little big so let's narrow it down a bit. We can look to other object made by human hands: architecture, film, and mechanical objects.

Here we are looking more at product than process. To do this we need to reset and start with a beginners mind. Look at these new things with fresh eyes. Look for the complexity of everyday gestures.

Architecture

Start with the Winchester Mystery House. The woman who built this house kept building it in the hope that if she kept building she wouldn't die. This mess of a house is what you don't want to be inspired by in architecture.

So what can we learn from?

Houses, however, are particular interesting because they are where people do a small amount of work. So what is it about these things that we can learn from?

A building must do two things: it must shelter us and it must speak to us of the things we find important and need to be reminded of. John Ruskin

Buildings must be strong, useful, and aesthetically pleasing.

Compare the floorplan of a modern building with a Victorian building you see that houses now devote tremendous real estate to the garage while Victorian homes devote more space to socializing.

In essence, what works of design and architect talk to us about is the kind of life that would most appropriately unfold within and around them... They speak of visions of happiness. "Alain de Botton":http://en.wikipedia.org/wiki/Alain_de_Botton

Now look at Twitter and think about what matters. It is all about YOU and what YOU have to say. The Victorians would never build something like this.

What works for the design of a church won't work for McDonalds or for your house. Think about web pages and applications from this perspective. The standards are just patterns that we should tweak to meet the design problem we are trying to solve.

Have nothing in your house that you do not know to be useful, or believe to be beautiful. "William Morris":http://en.wikipedia.org/wiki/William_morris

Look at the Gamble House.

Though large, the home is very approachable. There is a lamp near the door to light the way but it also holds the house number. Instead of marring the door with the number, it is integrated into the lamp.

Yahoo is doing something similiar with their menu bar. They use the menu bar to adapt to use and brilliantly integrate form and function.

In the living room of the Gamble house there is this amazing fireplace. The ceiling is designed to denote separation within the space. There are built-in cabinets in different spaces designed to hold the materials that will be used in that space.

Adobe uses a drawer metaphor in CS3 to similar effect.

In the Gamble House, even the functional is made beautiful. The straps attached to the ceiling beams are designed. The attention to detail is deeply beautiful. It demonstrates what is important to the designer.

Film

Film is all about movement. There are many pieces to film.

Remember the scene in Indiana Jones where he is flying around the world. This inspired Jeff Veen to solve a design problem in Google Analytics.

If you watch The Birds you'll notice that there isn't a soundtrack for most of it.

Science fiction can be very inspiring. Think about Minority Report and then watch Jeff Han's multi-touch interface.

Title credits can also be very inspiring. Saul Bass's titles for Anatomy of A Murder and Psycho are great example. This art form dropped off for a while but movies like Seven and Catch Me if You Can are bringing it back.

Look at the Digg Swarm designed by Stamen and you will see how movement can make for amazing interactive experiences.

Mechanical Objects

Why look at mechanical objects in our digital world? They have been around much longer and we have stolen many interface design metaphors from them. Our digital products just haven't had the time evolve that mechanical objects have had.

Compare the Braun calculator from 1972 and the iPhone.

Dashboards and control panels are a great place to start. They are made up of:

• displays
• controls
• labels

Displays give you information, controls allow you to manipulate the system, and the labels tell you what the controls can do.

"Invisible State" dashboards tell you what is happening inside something that you can't see. In this interfaces, display is very important because it communicates the state of the system. You see this in many executive dashboards.

"Infrequent-use control panels" are the opposite. The display is a small part of these panels. Controls and labels are huge. In these situations, the display can act like a label. We see this in kiosks all the time.

"Direct manipulation" consoles almost eliminate display because the feedback is right in front of you. Think about a crane operator's control panel. He or she can see the crane swinging and doesn't need a display to tell this.

We can learn from the parts of mechanical objects and break them down.

Look at the design of the controls on a Vespa. Toys are also a great source of inspirations. Look at the typography on a 1951 Hudson Hornet. The way that type is used give the interface a very specific feel.

There are a number of very basic lessons we can take from physical objects:

• Labels should connect to controls
• Icons are hard
• Icons are really good in some cases
• Make clever controls

On this parking meter example there is a "maximum time" button. This anticipates a common use.

But mechanical objects also show mistakes. Don't label your labels. This shows that you have designed it wrong. Don't make things look like buttons that aren't buttons. If you have to tell people where to start, you are probably doing it wrong.

Conclusion

When it comes time to design the next thing, step out into the world and look around for inspiration.

Q: How do you work across disciplines, and get inspiration from your own products?

A: This is an interesting problems. How do you introduce a paradigm across design languages? Don't really know the answer but it is a very interesting issue.

Q: Many of the examples of bad design you showed are patches applied later to fix an initially bad design.

A: It is much harder to fix atoms than bits. "We've already got these things out there, how do we fix this?" Some of the fixes do help people use the product but there comes a point where too many Band-Aids make your thing all Band-Aids.

Q: Glib response to the earlier question about inspiration from your own products. Go back to WWAD. Apple has an amazing design language across media from software to hardware to physical stores. To go back to the iPhone it is amazing to see how effective animated transitions can be when they are done well.

A: Exactly. Transitions really give it character. The movement, the tissue between the features is so rich that it is a hard thing to pull over. It isn't about features at that point.

Q: Can talk about where this idea came from you and how you got started?

A: Inspired by Bill DeRouchey's work. Keeps a library of these examples and thumbs through them for ideas. Think about what your problem is like and then look for how other people have solved it (across media). It isn't perfect but the point is to use these things to refresh when you get stuck.

Q: What about when users fix bad design in the world?

A: There is a book about these things, the workarounds people have done to fix broken things in the world. Some of these are much better than the design choices made by professional designers. If you see these when you are doing contextual inquiry and ethnography work you can learn from them.

[Live blogged from Adaptive Path UX Week '07. CNN.com Relaunch Case Study with Lori Adams and Dermot Waters from CNN]

Purpose: relaunch CNN.com to give the user a more compelling and useful destination for news on the web, utilizing any new technology.

Started with an 11-step process document.

Step one was discovery. This involved sitting down with every type of person in the organization, user surveys, user behavior data analysis, competitive analysis, persona development, and an assessment of the technology landscape.

They learned what ideas existed in the organization and what people wanted from CNN. Adaptive Path helped with competitive analysis and persona development. They did a user behavior study involving 24 users to understand how people use news online and how this online behavior fits in to their news consumption generally.

This kind of research was new to CNN but the organization embraced the personas. The 6 user types helped to change the conversation.

For a presentation to CNN big-wigs they handed out t-shirts that read "We are not our target audience." This idea actually came from management.

After personas, the next step was to create a directional statement. They took everything from the discovery phase and processed it into a coherent direction.

1. Define a new standard for the online news experience
2. Present a unified, comprehensive view of the scope of CNN's brand offering
3. Focus on content that aligns with user behavior
4. Connect users with content personally relevant to them
5. Maximize the value of CNN's human perspective, assets, and expertise
6. Improve productivity, agility, and flexibility of CNN.com

In addition to these six objectives there was a list of what they wanted to accomplish followed by another list of why they wanted to accomplish these things.

The took this directional statement and moved into the next phase. They broke into eight working groups who were assigned clear mandates including tasks and deliverables. This process took input from 65+ staff members from across the company. The outcomes were then fed back across all groups in CNN and Turner. They then distilled these outcomes into the core feature set.

From this, six cornerstone concepts emerged:

1. Integrated storytelling
2. Connection
3. Participation
4. Personalization
5. Linking

To communicate these underlying concepts internally, Adaptive Path designed a series of posters to go up around the office. They also had a clear elevator pitch that was repeated and repeated.

The story page is called a "mosaic." Before a visual existed, this term enabled them to talk about what they were aiming at. The "minor topic page" is another example of this. These landing pages are completely automated based on taxonomy and ontology. They can then take these ontologies and layer editorial content on top of this. A "special report" is easy to build when you take advantage of this automation. They added commenting as a first step toward user participation. They are starting to do more with this. After the bridge collapse they invited people to submit stories and videos. This material was then used throughout the network on TV, etc. They decided to do passive personalization.

Linking was a totally new concept. They consciously decided that they wanted to be a good web citizen. They realized that this would generate traffic and tell the story more effectively.

This site is designed from the idea that users do not always enter from the home-page.

After they had all of these concepts, they started with a simple conceptual prototype. This was the first time they did this kind of prototype testing.

After testing they partnered with a visual design firm but when the design phase was complete they decided to throw out the process document. They picked a date a set a schedule working back from that date. They refined this schedule to include ALL aspects of the project including stakeholder reviews, time to make changes after reviews, etc.

The team was sequestered. They called this the "Relaunch Protection Program."

As they built, they used a wiki-style tool for requirements tracking. This was a HUGE success though they eventually moved to a ticketing system.

The beta was a new idea for CNN. The biggest hurdle was double publishing because it was a huge change in workflow, CMS, etc. The hardest day of the whole project was when the beta launched. There were three stages of feedback: Baseline, beta, post-launch.

Q: How do you evaluate success?

A: Research is working hard on understanding how this has changed. The feedback via opinionlab comment cards was very helpful. There was a dramatic shift from design to editorial and that's when the new that the design had been accepted by the audience.

Q: How does your team work?

A: The team evolved throughout the process. A big change was from the system driving the human processes to the human processes defining the system.

[Live blogged from Adaptive Path UX Week 2007. Mobile Research Techniques by Rachel Hinman]

How people access the internet on their mobile phones is a a challenging research question. For most people in the world mobile + internet is an awful experience.

It seems people want to use the web differently on a phone than on a PC. A mobile phone is not a PC.

So let's go back to the 1950s and think about punch-cards. Imagine what computing would be like if we hadn't gotten past punch-cards. We have to change our thinking to shift our perspective.

People use mobile for quick checks, to dip in and dip out. Success isn't measured by how long people are at a site on mobile.

When you are using a desktop you are seated in a controlled environment. They have a large screen with an attached keyboard and mouse. The interface has layers and options that are ever-present. These factors combine to create a sense of engagement.

When you use a mobile device you could be anywhere. Compared to a mouse and keyboard, the input options are greatly reduced. Most apps run full screen on a small screen. You can only see a few things at a time.

Think of using a desktop as scuba diving and using mobile as snorkeling. Compare e-mail to SMS and Twitter.

Design for partial attention and interruption. Rethink how you measure the success of a site or application; engagement is not what you are looking for. Design with interruption in mind. Create experiences that are ideal for "skimming the surface." Consider passive forms of content consumption.

They call it surfing for a reason... User Interview subject

The way the Internet is structured today is oriented to Information Architecture; a discipline born out of library science. On the web today, people search and find. On the phone this breaks down because it assumes that you know what you are looking for. The affordances aren't built in to allow you to do this effectively.

Remember mix tapes? Back in the day music was organized by album and mix tapes represent a fundamental workaround. People wanted to create their own albums.

People want information, not URLs. People do more with this information than search for and consume it. They keep an eye out for mix tape-like workarounds. We need to liberate information from the page by privileging XML over HTML.

People check for three things on their phone:

• News
• Weather
• Stocks

Q: The role of the environment seems very important here. You want the device to be exceedingly predictable.

A: People want content to be exciting, engaging, and relevant.

[Live blogged from Adaptive Path UX Week 2007. Going Mobile: How to Choose Target Platforms and Devices by Barbara Ballard]

Mobile platforms:

• native apps (UIQ, Symbian, ARM, Palm, Windows Mobile)
• messaging apps (SMS, MMS, etc.)
• web (iMode, WML, XHTML Basic, XHTML MP, ECMAScript)
• app multi (Java, Flash Lite, mojax, BREW, SVG)

So how do we decide what to do? Use needs-based thinking. Start with a class of technology based on application and user needs. Choose the specifics based on market, distribution, and internal needs.

Mobile needs come from users and context. Remember that a mobile device is always carried. It is a fashion statement, it is a part of who you are but this has many implications from the size of the screen to the input mechanism. The device might be away from connectivity.

Pick something you are working on and keep that in mind throughout to help evaluate platforms. Think about:

• reliability of data access
• interaction flow
• interaction richness
• glance-ability of data

Your target market will define the device you choose. Business users carry smart phones and consumers mostly carry "feature phones." In africa you will see people carrying smartphones powered by Symbian and Windows. These people tend to use these devices instead of computers.

[Live blogged from Adaptive Path UX Week 2007. Semantic Technologies by Cameron Hunt]

Dynamic context to search, display, and workflow

What are Venn diagrams? Relationships, overlap. What is context? Relationship.

Background

Why do people cut their hair the way that they do? Why do they wear rings, etc.?

As a missionary in Venezuela he learned that community is the single most important influence on behavior. Think about yawning and the cascade of power.

Social narrative driving sustainable change.

Combining experience in anthropology, technology, and military intelligence to think about these issues.

So what is context? Concentrations of influence interacting in time and space. Boundaries, interactions, causation, influence.

So what are semantics? Aspects of meaning expressed as language. Axioms, concepts, rules.

All of our concepts and relationship are based on concepts that define how we categorize and organize.

So what are semantic technologies? Mathematicians have formal logic and we want computers to have this to. These are ontologies. This is expression in a standard format. We then want inference engines that discover implicit connections between concepts enabling dynamic context. This is where emegence, self-organization at a meta level, starts to occur.

Vietnam = Impedance Mismatch

The narrative did not fit reality. Successful corrective action was bottom-up. Terms were redefined, new ones were introduced. New "characters" were added, people assumed new roles. Technology was adapted to fit the new narrative and reality.

Iraq = Impedance Mismatch

Micromanaged narrative, changing reality. Corrective action reached political/military boundaries. There are some successes: CIDNE and Human Terrain System.

These solutions also emerge from the bottom up and emphasize the importance of local political considerations.

So what do we learn from this?

We want more expressiveness and new capabilities.

We need to separate data from concepts models. We want multiple hierarchy types ("is a" "part of"). Powerful relation properties emerge from this that are transitive and symmetric. We can do inference based operations (search, display, workflow), control concept access, and evolve concepts.

So do we let end users create new entities? We are talking about taking data and letting people create new structures, new combinations. This let's us connect diverse communities (federation, integration, association) with flexible/sustainable data mapping. Map Service Oriented Architectures to

Check out ILOG, Thetus, and Liferay.

So let's define some terms.

A Personality is a collection of ontologies and data. It provides foundational context for search, display, and workflow.

Think of the data structure in a simple structure. Map relationship properties and data type properties. These properties have domains and can be dependent.

Constraints can be concepts, properties, and instances. Individual search result items return dynamic property lists.

[Basic Search Demo]

This structure let's you put data anywhere and map concepts across data sets.

Let's look at domain specific ontologies. Unique ontologies provide concept model evolution, allow for protected access to concepts/data, and can be merged with other concept models. You can hide concepts, and assertions made on those concepts, until they are properly evolved. You can define behaviors or low-level relationship characteristics as sub-sets of other relationship characteristics. An abstract concept model allows you to map sub-concepts.

[Live blogged from Adaptive Path UX Week 2007. Pattern-Based Design Communication Techniques]

Why document design? It helps facilitate collaboration and move the design process forward.

• Visualize solutions
• Something tangible
• Encourages people to commit

At Cooper work is done in small agile teams. The core team in an interaction designer and a design communicator. There is also a visual design lead and engagement lead.

We are talking about interaction design today. ID is responsible for solution ideation through sketching rectangles on a white board. They are to keep the momentum going and produce final pictures.

The DC is responsible for the design making sense, for testing the ideas that come out. They are looking for patterns (design patterns) that make sense for this problem. They create the book, presentation, or notes that tell the story of the design.

This is socratic relationship between the two. ID sketches, DC asks questions. The other members are also there along the way but are included at key moments (daily).

Documentation, delivery, and design are all about story-telling. The process is anchored by personas, propelled by ideal usage scenarios, and tempered by the reality of engineering constraints and other requirements.

So when does design happen?

• During and after research
  • to discuss preliminary findings
  • To communicate behvior patterns, personas, etc.
• When we define solutions
  • To out line napkin-sketch solutions
• To specify refined interactions
• Throughout the process
  • To document key decisions

Patterns outline solutions to common problems. The patters concept comes from architecture.

A pattern approach subdivides one large problem into many smaller problems. instead of addressing documentation as a monolith you are addressing the problems you are solving with the documentation.

[See the slides for a good list of challenges in documenting design]

A case study

Client: Barclay's Global Investors

Project: A web tool used by financial advisors to explore new ways of analyzing portfolios and understanding performance

Can't focus on analysis part of the project. Can talk about getting information into the site.

• provide efficient pathways to entry
• help advisors avoid mistakes
• handle errors smoothly and helpfully

Start with a persona: Steven the broker from a full-service brokerage who needs a story to sell to his clients. He already has a dozen and a half tools he is already using.

His goals:

• Win new customers
• Appeal to as many people as possible
• Stay on top of current trends
• Not to waste time

Barclay's wants Steven to think about iShares as a family of products, not as stocks.

Start with a sketch solution. Brand agnostic colors and focus on the parts that matter. There is a visualization of the portfolio.

So uploading security data...

Assets are already in spreadsheets. The people who have financial advisors are wealthy. These people have more than, let's say, five million dollars in assets.

So you take that spreadsheet and upload it. The area below indicates that something is happening. The advisor is prompted for a notes field. Once the results appear the app will need to handle errors.

So do document this you need a patterned approach.

Scenarios show behavior in the context of the problem they solve. They communicate the narrative of the design, they keep you rooted in humanity.

A scenario shows a series of pages as a persona goes through a task.

Screen layout diagrams describe important elements and behaviors. It roots the screen in context with the workflow. We are talking wireframes at this point.

Global behaviors and principles for solving common problems. Similar problems = similar behaviors.

Use a table of contents to structure the documentation in a way that communicates the purpose of each piece in relation to the whole.

Q: What about rich internet applications?

A: Powerpoint animations are useful. Documentation can present a ton of overhead, even to make an animated gif. You want to avoid spending too much to make documentation. Flash demos can be useful for this (especially with demoing physical objects that make sound, etc.). Bringing it to life is very important.

Q: How do you use design patterns across projects?

A: This is hard to do because if you emphasize story-telling you reinvent quite a bit every time. They do, however, maintain an archive of previous solutions to build on.

Q: What's in the style guide?

A: This is very high fidelity. This is where the rendered interface is documented along with typographic and color system information.

Q: Who uses this material? and how?

A: It depends. The reality is that there are many customers for the documentation. There is the executive who brought them in, the product manager who is wrangling everyone together, and other internal people. The executive summary presentation will be tailored to that group. Note like check-ins will take place with the product team along the way to keep things on track.

[Live blogged from Adaptive Path UX Week 2007. Waterfall bad. Washing machine good by Leisa Reicheit]

Came at UX through project management.

Back in the days of yore people would write functional specs. They would be signed off on, set in stone, and put into production. Theoretically, knowing the end goal would let you estimate costing, etc., in a project.

But in reality this doesn't work as promised.

[Great story about a project where they decided to attack small problems on a site instead of jumping head first into a giant redesign. The lesson is that there are many ways to manage projects and they are all valid if chose in the right situation.]

Caveat: this is focussing on the positive. There are problems with Agile but we are focussing today and its advantages.

Waterfall = Bad

Scope > design > Build > Test

Why is waterfall bad? In 1970 W. W. Royce outlined waterfall among other methods. He didn't have good things to say about it.

I believe in this concept, but the implementation is risky and invites failure. W. W. Royce, Managing the development of large software systems

Waterfall is bad for designers

• Assumes that you know what you are doing at the beginning. This is rarely true. In fact, in the best project you know very little at the beginning.
• Assumes that there is a point in the project where design stops. This never works. When you hand something to developers and watch it come out the other end you know that design hasn't stopped. So why leave designers out of this? When technology smacks design in the face the designer should work with the developer to make solution. Design decisions at all point should not happen in a vacuum. Developers should be brought in to the whole process and not just get the end deliverable.
• Discipline discreet phases keep people apart. This diminishes the work environment. People don't learn as much this way. We learn more if we are working with all different disciplines.

Waterfall is bad for humans

MCC did a study on this in the 80s. Watching how people actually work on projects they learned that people don't cleanly divide their work between understanding the problem and exploring solutions. Waterfall assumes that these are completely discreet.

Waterfall does not support the way our brains work.

Washing machine is better

This isn't an accepted term for a methodology so let's explore this.

• Iteration at every step
• Early and rapid release of prototypes and products
• Multi-disciplinary in the same room and on the same task
• Collaborative throughout the whole process
• Involves real end users in the whole process

So what's out there already?

Agile

This is becoming more popular in the last few years. Scrum, a flavor of Agile, dates back from 1986. This can also mean working quickly without planning but that isn't really Agile.

Agile is not Ad Hoc

Agilists have lots of rules. They are very conscious about what they are and are not doing.

Waterfall is predictive and Agile is adaptive.

Agile is:

• Sprints/ time boxes
• User stories
• Pair design/ programming
• Close proximity teams

Agile is all about working software at the end of each sprint.

Start with a story > Fine tune the details > Build something > Test the thing against the story

User Centered Design

• Iterations
• Personas/ Scenarios
• Contextual research
• User testing

So what..

Agile is weak on user involvement. UCD is weak on multi-disciplinary collaboration, it is very design focussed. UCD is also weak on early release.

The best way to do it is to start with Agile and add in UCD techniques.

Cycle Zero

This is what happens before the project begins.

Do this when a project needs up front research and high level design strategy. This takes time but don't forget that you are trying to be agile about it. Stick to short time frames (2 to 6 weeks) and deliver something that works, not working software but shared goals or vision.

Cycle One

How much design can you do in this cycle? How much testing can you do in this cycle?

Cycles should be 2 to 4 from start to completion.

Mid-project cycle

(This is a Venn diagram when you aren't writing your notes in words...)

Designer

• test previous
• design next
• research next

Developer

• implement design from previous

Both

• feedback on design
• feedback on implementation

Conclusion

Now is not the time to become a purist about methodology. Pick and mix from whatever works and build something for your context and your team. The time for buying project management methodologies off the shelf is behind us.

[Live blogged from Adaptive Path UX Week 2007. Sketching in Code: Using Prototypes to Visualize Interactions by David Verba ]

With the Measure Map project they were able to build working prototypes right away. This enabled them to rapidly iterate with functional pieces.

An engineer should never be more than a stones throw away from a physical product. Kelly Johnson, Lockheed Skunk Works

A design/development process should never be more than a stones throw away from a working prototype. David Verba

Sketches

From rough to detailed engineering graphics. Designers use this to deliberate effect. Developers can do the same thing. They start with a rough code outline and sketch as they work away in code.

Advances in the last few years have made this easier. Two developers in an afternoon can produce profound results.

For the context of this session we are talking about interactive screen based prototypes.

Low fidelity or high fidelity.

Why prototype?

Wireframes just don't cut it any more. As we build more Ajax applications, wireframes can't document this.

It is cheaper to build prototypes than to design wireframes and pass them around. You are trying to figure out why things don't work in the wrong medium. This is expensive.

The goal of the process isn't to produce perfect documentation, it is to build a rapid working prototype.

Prototypes can contain the magic, the emotion, of the real thing. A wireframe just can't give this to you.

Where can we prototype?

• Exploration into divergent ideas.
• Collaboration & development. See what you are building come to life every day.
• Deliverable. Give your working prototype to your client for them to build out.

Who is the audience for a prototype?

The design team can work around a prototype with the development team. But there are other audiences too.

Internal stake-holders and users can also see in prototypes the character of the application and give useful feedback.

Advantages

Prototypes let you see problems clearly right now. You don't see things coming down the road that you can't do anything about. Instead you make them happen right now and deal with them. Prototype the issue and the solution to keep evolving your project.

Reveal problems that typically don't emerge until much later. Prototyping helps you avoid being blind-sided.

Prototypes can get you buy-in from stake-holders. Show how it works now and then show how it should work.

Use prototypes to foster collaboration between disparate groups. The traditional divide between designers and developers is unhelpful. Building working prototypes breaks down these barriers.

This all helps everyone understand the whole project and what is possible.

Challenges

If you don't have access to front-end and back-end developers that will limit your approach. It is not a deal-breaker.

Low-fi is hard to sell. No matter how functional it is, people don't understand why is looks like that. Hi-fi is hard because people ask about the wrong details. Sketch for what you are trying solve.

Think about the amount of effort and resource you are going to put into polishing your prototype.

Annotation is difficult, you have to be careful not to lose the history of the application and the decisions you've made. Map this out the best you can.

Solve the right problems. Don't waste time setting up your prototyping framework. Focussing on the prototyping methodology misses the point. Just get started, grab a pencil and go.

Techniques

HTML and javascript are a great way to get started. Build simple click-through prototypes. Think about Tiddly-wiki. You can do amazing stuff with HTMl and Javascipt. You do need a front-end developer to help with this.

This can be hard when you need to be modeling a large amount of data. Use JSON and XML on top of your HTML/JS prototype.

MVC frameworks (Rails, Django, and catalyst) are great for prototyping. These allow you to build web applications very very quickly with code that you can use in production.

Flash and flex are very useful for rendering rich interactive interfaces in prototypes. We are not talking about overly animated interfaces. This is a question of discipline to model what you actually want to build.

Open Laszlo is another framework. It is a widget framework. There are drawbacks because of a limited number of interactions you can model. It is easy to visually style and can easily point to XML data sources. You don't have to be a front-end developer to learn it. The biggest downside to this is that your code will not be reusable. It is a pure prototyping framework.

Aure and Irise are also out there but they are PC only and they are very expensive. However, people that use these in corporate environments tend to like them. You can drag and drop interactive elements to build a prototype. These frameworks also generate documentation.

Closing thoughts

So what about the distinction between prototyping and agile development. If you can get to a working application early on it can keep everyone focussed. You see the impact of your decisions right away. This is THE best approach.

There isn't one monolithic approach to this, so just play with the tools.

What do you do to get started? Start asking about the resources you already have. Do you have access to front-end developers? Feel free to start small and build from there. Model a page or two and see how that goes. Get buy in and pull in resources from outside your immediate environment.

[Live blogged from Adaptive Path UX Week '07]

The only problems designers get to work on are the ones they are hired to fix. AP was looking for a new challenge and took on the insulin pump.

They designed the charmr to improve this awkward device. It integrates the pump and monitor into one device. An external charm controls the device wirelessly. The main device is worn beneath the clothes and is soft and flexible. A monitor is inserted into the skin and finger pin-pricking is no longer needed.

The external device displays both monitoring data and controls for dosing with a variety of context specific modes.

For more, see http://www.adaptivepath.com/charmr (when they post to this location)

The original idea came from a woman named Amy Tenderich. She wrote an open letter to Steve Jobs asking him to improve the design of an object that people wear every day: the insulin pump.

Medical objects are often designed from the perspective of engineering and physicians. Current insulin pumps are ugly and unpleasant.

AP started by talking to diabetics. They did rich ethnographic research exploring both the home and how the product is used out in the world. It was emotionally difficult research to do because it is a difficult condition for diabetics to live with. The goal was to make something that makes these people's lives better.

Diabetics have to be constantly conscious of their condition. It required a certain kind of personality to make this work, but tools can help mitigate this. They have to consider day-to-day choices in a long-term framework.

They mocked up examples of the equipment and wore it around. They bought test strips and pricked their fingers. They learned that this equipment is expensive and hard to use so people use it less than they should.

They explored what the diabetic needs to understand about themselves. They check their status, calculate, and adjust their dosage. They have to wear the device and keep themselves motivated.

Sometimes I wish I just had cancer instead. a patient

Because the current devices are clunky, it is very hard to do normal activities with them, like sex. Patients feel dehumanized by their condition because of this equipment; they see themselves as cyborgs.

They came up with a ton of ideas that were thrown out. But that is the point of an exercise like this. At one point there was a "third boob" concept. This was crazy but the idea of the pump being a part of your body emerged from this discourse.

If you hide the device in a flesh-like cutlet, what could people use to control it? They thought to make it like a piece of jewelry, like a mood ring for your condition.

The ambient display of this device is designed to give subtle, meaningful feedback. They struggled with what could be displayed on a thumb size device. They designed interaction flows for the medium. While many insulin pumps are as big as a PDA, many diabetics do all of the needed work on a pen size device.

The other innovation with this concept is the connection between the monitor and the pump. This continuity of information allows you to build a device that learns from your behavior and can make meaningful recommendations.

Q: What next?

A: During the process they worked with Amy Tenderich and she was excited about what they are doing. She talks to diabetics and device makers. She would like to see someone produce the device.

Q: How can we get this done for more problems?

A: This method works but this solution isn't the only way this problem could be solved. By putting the research out there they hope to start a conversation.

Q: What was the timeframe for this?

A: About nine weeks including design and research.

Q: How can you make it real?

A: There are many considerations that AP doesn't understand but someone who can should step up and take it up. The thing AP understands is how to design for the user experience. Part of the value of this exercise is to show the value UX in product design.

Q: What about diabetics who can't use the insulin pump?

A: Started by talking to both Type 1 and Type 2 and decided to focus on Type 1 diabetics who must regulate their insulin. Focusing on them enabled them to think of this device.