IA & Interaction Design

May 15, 2011

Moving the blog

The Vanity Experiment is moving to

Small change you won't hardly notice if you're browsing online, but if you're reading this via a RSS reader, you'll want to go change the feed address to this: feed://

Why the change? I've been using Movable Type version old.OLD since about 2004, so I decided to get with the times. Bring on Wordpress (which is now running my entire site).

Posted by Ant at 12:41 AM | Comments (0)

February 22, 2011

Interface Spelunking

I recently posted a slightly nerdy interaction design blog post over on the Different Website.

Spelunking is an outmoded term for ‘caving’ - the recreational sport of exploring caves. It can also be a metaphor for user interface exploration, where a user must explore the features or content of a system by diving deep into a ‘cave’ (i.e. area of a system) to do a task, only to need to come out again to do the next task or step.

Interface Spelunking Part 1

Posted by Ant at 09:04 AM | Comments (0)

April 29, 2010

Visual Vocabulary for Rich Internet Applications

About three years ago, I presented at UX Week 2007 on a topic that in hindsight, probably was best left to some kind of tutorial. At the time, I had been specifying the interface behaviour of highly conditional and rich internet applications (think flash, ajax, etc) through an adaptation of Jesse James Garret's Visual Vocabulary.

I just stumbled across the old presentation and took another look. It's not all bad, though I think I completely lost my audience given the convoluted nature of the topic. You would be forgiven for enquiring whether this is a good use of time - diagramming rich interface behaviour - when you could be prototyping the interface instead... it smells a bit like documentation gone mad.

It was at least an interesting thought experiment and one I'm posting it here because maybe one day, someone will find it useful for something. If you do, let me know.

Posted by Ant at 11:48 PM | Comments (0)

April 28, 2010

The next frontier: Designing for Emotion

Aarron Walter makes some salient points about designing products to elicit an emotional response over on Carsonfield's Think Vitamin. He makes a nice analogy that usability is equivalent to edibility of food. Yes, food has to be edible. But what about tasting good? That's how emotional response equates to design.

"Positive emotional stimuli can build a sense of trust and engagement with your users. People will forgive your site or application’s shortcomings, follow your lead, and sing your praises if you reward them with positive emotion."

So, I wonder in what circumstances we may want to provide people with something other than positive emotional stimuli through our products and services?

Posted by Ant at 03:51 PM | Comments (0)

October 09, 2009

We're still too fluffy

OZ-IA is an information architecture conference held here in Sydney annually. I presented this year on a topic which has occupied me the past few years: Selling user experience design and the value of design thinking to business.

The thrust of the presentation goes like this:

  1. We, as a profession, have largely failed to make great product experiences.
  2. There are certain people that matter in the world of design, and it's not designers. It's the people who pay to have things built
  3. Communicating the value of design to people who pay to have things made needs to be better done by the industry. They call this "Selling" and we can learn it from traditional salesmen.

Posted by Ant at 09:19 PM | Comments (0)

April 30, 2009

Something I presented a while ago...

Posted by Ant at 01:18 AM | Comments (0)

July 20, 2008

UX Dreamteam Part 2

The second part of the article I've been chewing on for the past while is now up on Boxes and Arrows.

Building the UX Dreamteam - Part 2

In this second part of a two-part series, UX manager Anthony Colfelt follows up with some solid considerations when looking for your next superstar. Building a dreamteam goes beyond looking for tight technical skills: personal chemistry is needed to find that perfect match.

Posted by Ant at 04:42 AM | Comments (0)

June 05, 2008

Information Visualisation Library

Christian Behrens has done a very nice thesis on Information Visualisation and put the bulk of his findings into a pattern library website. If you like Tufte, better sit down. This site one made me come over all funny.

Posted by Ant at 10:34 PM | Comments (0)

January 20, 2008

Microsoft Expression, WPF and UI Designers

The latest project I worked on used Microsoft's Expression suite to deliver a working prototype of a Windows application in Windows Prenentation Foundation (WPF). Expression is actually four different programs: Design; Blend; Web and Media. Clearly aimed at taking some of Adobe's market share they enjoy with Flash, Dreamweaver, etc, Expression can deliver Web sites, applications, "Silverlight" (can be thought of as a Flash-like plugin that plays Silverlight files in a Web browser), rich apps and also Windows Presentation Foundation (WPF) apps (Lots of MS Vista was built using WPF I hear). XAML is the main code format that Expression produces. XAML is a language that describes the interface layer, and is similar to Scalable Vector Graphics (SVG) in its appeal (rendering of interface objects as vectors based on code rather than as pixels which don't scale well).

Expression facilitates workflow between disciplines in the development team as it separates the presentation layer from code quite well. Both can be generated simultaneously and there's no longer a need for a developer to translate a designer's vision with lines of code - invariably a vulnerable communication process. Well, that's the promise anyway... but yes, there's a big 'but' here.

Leaving aside the immaturity of the application suite, while relateively slick for a Microsoft product it has got some nasty usability issues. In terms of flow, it runs a distant second to Adobe's products, which have been refined over the last decade and a half or so. Indeed, getting around some basic functions like relabeling layer elements seems like a chore by comparison. Unfortunately, the fact that an interface has been designed over the top of an underlying interaction architecture defined by programmers is fairly typical of the way Microsoft builds software. Credit to the design team who did a reasonably good job at pushing boundaries where they could and put some very pretty lipstick on this little piggy. Not all the applications in the suite are difficult; the 'Design' tool isn't too bad. It's not as powerful as Adobe Illustrator, but pretty similar to it for the most part. But where Microsoft had to invent something that didn't have a good example to follow (e.g. the 'Blend' tool), the resulting software is cumbersome for we UI designers to use.

The 'Design' and 'Blend' tools share some of the same functions, but ask the user to learn slightly different interface paradigms to do them. This contributes to the feeling of "anti-flow" aka 'frustration' that washes over you when trying to do things that could be done simply with Adobe products.

'Blend' when working in WPF is trying to create a very different underlying structure to interface objects than designers are used to thinking about. Grids, Stack Panels, Frames and other 'Containers' are a foreign model when you are used to just placing bunch of elements onto a page so they look right. This takes some getting your head around to say the least. Supporting documentation on when to use what 'Container' and why some 'Containers' are better suited to certain applications is not comprehensive. Add this learning curve to usability issues and frustration turns to exasperation rather quickly. Some may retreat to the familiar, comparitively friendly environment of Adobe Illustrator, exporting XAML from it using a plugin (which doesn't do the cleanest translation job either) and giving that to the programmer to construct the 'Container model'. That kind of defeats the point of Microsoft Expression if we're trying to get designers to put their edits directly into code via 'Blend'.

Perhaps its unfair to compare a product that's just recently come to market with one that's been honed over time and does something fundametally different. But with that said, there are some things that seem patently broken about 'Blend' (known bugs aside).

In my experience, developers hate using WYSIWYG tools because they don't do a very good job at interpreting intentions and create overweight and messy code as a result. In essence, that's what 'Blend' is - a WYSIWYG code editor. Typically, your programmer won't want to use 'Blend' to create the complex, object-oriented control structure inherent with software of any magnitude. They'll most likely want to use Microsoft's Visual Studio instead because it's what they're used to and frankly is does a better job of helping them to code than 'Blend' does. In this case, you will run into terminal problems trying to use 'Blend' to edit design artifacts nested in controls (usually also fed content by a data source). This is of course, unless your developer is aware that you need to use 'Blend' to edit your design elements and structures their code accordingly. How you do that, I don't actually know. But I believe it can be done. If I find a link to something that outlines best practice for this, I'll post it to this blog.

In summary, I've used blend for about 4 months now. Not day-in, day-out, but for weeks at a stretch at least. I still dread opening it and battling through doing simple things. Toward the end of the project I've just finished, we were back to filing design bugs for developers to fix (or not) because we couldn't get at design elements because the project had not been architected 'just so'. So why did we use Expression? Is it just immature? Or is it destined to be difficult for designers to use? Only time will tell.

Posted by Ant at 04:10 AM | Comments (0)

November 29, 2007

Building the UX Dreamteam

After much writing and re-writing, the first part of an article I wrote called "Building the UX Dreamteam" is now up on Boxes and Arrows. Boy, who would've thought that putting together your thoughts could be so hard? I'm very happy that I had good editors, in particular, Chris Palle who really directed me how to cut this article into shape - Thanks mate.

"Finding the right person to compliment your User Experience team is part art and part luck. Though good interviewing can limit the risk of a bad hire, you need to carefully analyze your current organizational context, before you can know what you need. Herein lies the art. Since you can’t truly know a candidate from an interview, you gamble that their personality and skills are what they seem. Aimed at managers and those involved in the hiring decision process, this article looks at the facets of UX staff and offers ways to identify the skills and influence that will tune your team to deliver winning results."

Posted by Ant at 06:16 PM | Comments (0)

September 07, 2007

Visual Vocabulary for Rich Internet Applications

The Slides, Handouts and Podcast of my talk at Adaptive Path's UX Week 2007 are here for your viewing and listening pleasure.

If you'd like to join the myfamily site set up to discuss this topic, download the handout and see the last page for a link.

"Flow diagrams are a key component of an interaction design specification. Jesse James Garrett’s Visual Vocabulary uses a set of simple shapes to diagram user flow and illustrate basic relationships between webpages. However, using Visual Vocabulary to describe more sophisticated behaviors of “rich” interfaces — enabled by technologies such as AJAX, Flash and Ruby on Rails — can sometimes prove challenging. But with some additions and creative modifications, Garrett’s language can actually be used to effectively communicate the design of a rich or conditional UI.

In this session, you will:

  1. Gain a deeper appreciation of the power and flexibility of Garrett’s Visual Vocabulary.
  2. Discover how to utilize an augmented Visual Vocabulary to describe the dynamic nature of rich or conditional interfaces.
  3. Learn tips and tricks to improving your flow diagrams through the addition of key information.
  4. Find new ways to bring unrealized clarity to your specifications, illustrated via a series of specific examples."
Posted by Ant at 03:46 PM | Comments (0)

March 09, 2007


There's a relatively new web product (been blogging since May last year) out that caught my attention for its pure playability and potential to make web design/production accessible to the average, non-html literate Joe. Weebly is a WYSIWYG online web page builder that takes advantage of all the newest AJAXian and Web 2.0 technologies and presents them in an intuitive, non-threatening, explorable way.

Buliding a product easy enough to understand and use through futzing with it should be the aspiration of all designers. That the folks at Weebly have been able to make their implementation so smooth is credit to them. Props.

Not sure where the money's coming from, perhaps they're waiting to be bought. You could buy a lot worse if you wanted to provide your audience with a dead-simple away to get on the web.

Posted by Ant at 10:33 AM | Comments (0)

January 19, 2007

Fluid UI

Om Malik comments on the new fluid UI we're seeing emerge from Apple. It's particularly evident in the new iPhone apparently. I guess we'll have to wait till June to really play with it.

Toward the end of the article, Om points toward a trend that we're seeing not only in software for devices, but also on the web with the 2.0/Ajax delivered dynamic interfaces.

Designing for these interfaces raises some interesting challenges that are being more frequently explored in design conferences. The concepts of time, animation, ergonomics and information density are all heightened with the new world of UI design.

The iPhone has one distinct interface advantage over other devices in that it requires no input devices such as a mouse. Though our fingers are imprecise tools, we have more than one of them and I'm guessing the next frontier will be how we teach technology to understand the concurrent input of our many fingers.

I'm sure Apple had many chanllenges in designing for the clumsy finger. But this constraint has to have yielded creative interface solutions that overcome the physical size of the pointing device. I mean to say that Apple's designers were forced to simplify the interface so that it could be manipulated without error. I imagine with all that had to be taken away left not much left on screen to confuse the user. Fingers closely map to the imprecise nature of human behavior and comprehension.

It seems obvious now. Designing for fingers should open a new era of simple and intuitive interfaces. Thanks for showing the way again, Apple.

Posted by Ant at 09:42 AM | Comments (0)

August 14, 2006

So you think you are an interaction designer?

"So you think you are an interaction designer? Not if you cannot answer all the following questions quickly and with authority."

Bruce Toggazzini has a way of making me feel horribly inferior as an interaction designer... which is probably a fitting response to someone who is as knowledgable as he. Having written the book on interaction design for Apple and others, its hard not to get down on bended knee and mutter "we are not worthy".

This article goes into Fitts' Law, and is really useful for conceptualizing why as designers we do things the way we do, or should I say "Why we put things in the places we do".

Posted by Ant at 03:39 PM | Comments (0)

August 03, 2006

Minority Report interface & a glimpse into the future

Jeff Han presented at the TED Conference (Technology Entertainment Design) an interface that comes straight out of the movie "Minority Report" - its all dynamic and notably sans-mouse & keyboard or any other third party interaction device. I was blown away at how effortlessly Jeff seemed to be able to manipulate objects directly on a screen in this demo seen here. Using more than one finger at a time you can move, resize and position objects while the things on screen react very similarly to the way they would in the physical world. I think this is a glimpse at the future here, but actually realized, not a movie fantasy. Thanks to Dak Elliot for finding this one.

Another interesting phenomenon is the spot presenting the demo done by 'Geek Brief TV' which is a video podcast. In closing the presenter mentions she'll be haning out on Second Life, a social computer game that simulates reality.

Keep up Gen X... technology and society is moving fast. In that one Geek Brief TV spot, we saw three things that are revolutionary.

  1. A professionally edited podcast. That's the type of thing that will eventually end TV as we know it.
  2. An interface that signifies the next step in seamless interfacing with technology.
  3. A presenter who will be promoting her product, essentially doing business (as many now are) in a virtual world.

I'm feeling old all of a sudden.

Posted by Ant at 01:21 PM | Comments (0)

February 07, 2006

Being nimble to a fault

"The Company" has traditionally not been particularly agile at creating new products, or redeveloping old ones. In fact, until recenlty the technical architecture was such that it was pretty hamstrung in its efforts to make the most basic of improvements to the product. Larger changes took a very long time to develop, going through a gauntlet of a rigorous waterfall process before eventually being released to the public. The technical constraints heavily influenced the way work was done, because when changes take a long time to make its important that they're the right changes. New products or improvements were modeled and forecasted predicting revenues for executive review and prioritization; products were designed with care (if with more focus on the bottom line than the user) and development was slow involving performance testing and a many QA cycles before release. We joke now that the company operated more like IBM than an internet company.

With new and astute technical leadership, the company has begun the steady march to rebuild the infrastructure - readying it for faster development. But, culture is slower to change than code. We still tend to operate with the same deliberate, beaurocratic attitude. Change is hard for any company and it never comes quickly or without a few shocks to the system. We are receiving those shocks by way of a few 'initiative projects' by senior managment setting an example. With these I'm observing an interesting dynamic, something not totally dissimilar to post 9/11 USA where those who dared question the wisdom of the government were painted as 'unpatriotic'. When culture needs to change and the agents of that change encounter resistance to it, they'll toughen their stance to see their will enacted. Subordinates who wish to avoid lambasting (and gain political capital) make 'yes' their favorite word... and those that challenge the new "wisdom" are deemed 'old guard' and bypassed.

And so it is that with the necessary change to make the company more nimble and competitive, skills such as Information Architecture are discarded like babies with bath water. IA means thinking and planning and that would certainly not be nimble... Consideration for making designs usable and scalable is brushed aside with the glib notion "We'll iterate". But iteration doesn't happen when everything needs fixing. More 'initiatives' are launched to fix other broken parts and the old initiatives are destined to remain in beta versions. Strategy (which by nature is planning and therefore also taboo in the new order) seems as foreign as focus is to a child with Attention Deficit Disorder.

With the best intentions, one dysfunction is replaced with another.

Posted by Ant at 09:44 PM | Comments (0)

November 10, 2005

May 07, 2005

IA Summit 2005 - Dan Willis - Evangelism 101

Some more belatedly transcribed notes that I took at this year's IA Summit...

There are differences between Overt and Covert evangelism... choose which to employ based on your specific circumstance.

Enthusiasm - getting fired up about something is important. It is viral.
Group Dynamics - ensuring you're sensitive to how a group interacts.
Change - if you're not changing something, then you're not evangelizing, you're coaching.

'Change has its enemies'

IA Mechanisms to evangelize with:

Easy Sells: site maps, content inventories
Harder sells: conceptual wireframes, user task flows, non-linear interaction maps.

IA Building blocks

  • Primacy of user goals
  • User centered design
  • User research

Bad reasons to be an evangelist: Fame, power, it looks cool on a business card, chicks dig it. it's not about telling you what to do, its about getting people enthusiastic about doing it themselves.

Using evangelism for your own fame or power damages your credibility. Credibility is essential for an evangelist. Requires honesty, integrity , consistent excellence. The appearance of credibility is secondary

Good reasons to being an evangelist: The status quo is not enough. You have the passion and "mad" skills. You also just can't help yourself and are knitpicking about imperception and imprecision. Are you an evangelist and don't know it?

Evangelists solve problems rather than just alleviate symptoms. They trade ownership for consensus around new kinds of thinking. Evangelists act as if they are an outside consultant, whether they are one or not. They run workshops and initiate group creative exercises. Evangelists circulate information - email newsletters, collect timely articles from other industries. Psychology Today articles for example. A weekly newsletter is a good method to push people farther than where they wouldn't be pushed otherwise. Involving more diverse people than your group is a good way to start to create interest. Recruiting a few people to help with putting things into a centralized location is good.

Lead change from behind. Get people to run over the hill, but not by following you. The stimulate change by asking questions. They unearth and encourage expertise (especially under-appreciated expertise) They are a resource for, and supporter of other evangelists.

Eight Random rules of evangelism:

  1. Be shameless - do what you have to do to make change happen, no matter how personally embarrassing. Your Audience + your goals = your envelope.
  2. Be fuzzy. Skill sets are more useful than job descriptions. Utilize different levels of evangelism for different challenges or projects. Low level - newsletter. Med - involved in meetings. High level - redesign project
  3. Don't be fuzzy - demystify everything. Use existing words if commonly understood. If not, create a new common language. Utilize a common perspective - that's the beauty of user centered design. Demystify doesn't mean to explain absolutely everything - don't lecture.
  4. Be tactile - Bind squishy concepts to hard pixels. Action Items, High concepts/practical implications, illustrations, case studies.
  5. Own Minutia
  6. Fear the incremental. Incremental change is frequently is confused with evolutionary change.
  7. Encite the riot, but try not to lead it. You will be more effective if the self interest of those being evangelized is greater than their own.
  8. Protect your poets and pirates. Poets who tend to describe things in unique ways. and are those who are most likely to not care about working outside the normal. Rebels that don't play in the sandbox, but can singularly change the world. Pirates work together and rebel to create change. They resent attempts to protect them. They are sometimes surprisingly and fiercely loyal to the company. They dominate the sandbox. Keep them away from management. they cayn't appreciate them. Point them to ones who can. Translate their work. Over deliver on giving them credit for it. Praise of Poets must be meaningful and well-timed. Empower your pirates...

...out of time

Posted by Ant at 04:46 PM | Comments (1)

IA Summit 2005 - Panel - Social Classification (Folksonomies)

Some more belatedly transcribed notes that I took at this year's IA Summit..., furl, citeUlike, Wists, Technorati, live journal, flickr, vimeo, gmail, 43 things - all use social classification.

Types of social classification are broad and narrow. Broad: many users tag one resource. Narrow: few users tag one resource.

Folksonomy is about public tagging (vs private tagging on sites like GMAIL and Furl)

Issues with social classification are Retrieval, Quality, Authoring, Economics, Scalability, Usability

Peter Morville - Folksonomies... are they better than nothing?

Extremes of saying search is bad or search is good is not helpful. Apophenia - searching for the noise rather than the signal. Context is all important - is folksonomy relevant to categorizing a research site? Hierarchies and controlled vocabularies are becoming more relevant, not less.

Google is much better that Flickr. The quality of the search of flickr will decline as more people use it and the quality of the tagging decreases.

Google documents aboutness. The "linked to" value tells us more than the content or the metadata.

Five Lessons of Folksonomies
1. Leverage what already exists (or happens)
2. Tap wisdom of crowds (and users)
3. Tap compulsion to share (pennies not dollars)
4. Context counts (always avoid generalizations)
5. Never underestimate people's thirst for anarchy

Thomas Vander Wal - Folksonomy: a wrapper's delight.

Metadata: relatively hard, expensive, resource intensive, not easily emergent, can be hierarchical.
Tags: Relatively easy, generated by users for free, users have an immediate self interest, users find instant payoffs, emergent, flat.

Narrow folksonomy works best where the object does not have text that is searchable or easily found. It can be emergent.

Peter Merhorlz - Metadata for the masses

Uses wine classification as an example of how traditional classification 'blocks the light' from other taxonomies that may resonate more with users. Sometimes controlled vocabularies use terms that are foreign, or not appropriate for the content. This is a barrier to people tagging from a controlled vocabulary.

The entry of new terms into the social classification scheme is rapid and easy. New terms can emerge very quickly at a minimum of cost.

Seeing what other people tag things with influences what you tag a thing with.

There are issues surrounding synonyms. Sometimes things are just tagged incorrectly. Bad data is a problem. There are caveats to overcome.

Desire lines are worn paths [Note: this is also known as emergence]. Using folksonomy to pave the worn paths.

Merging folksonomies with established taxonomies may be a useful idea.

Folksonomies all allow for a poetry in classification that traditional classification schemes are scared to go near. There is a gut visceral level phenomenon occurring around what people call things. "me" is not "self portrait".

Findability vs Discoverability. Folksonomies can be inspiring because of their discoverability. The serendipity involved in typing a term (e.g. 'color') is very compelling.

Tag inversion - people are starting with the tags and then finding objects to fill those tags. This is the opposite to traditional approaches of tagging a piece of content. This is creating communities that surround the idea of creating 'square' or 'round' photo.

Are there contexts where taxonomies are completely useless? PMO - Yes, where people won't tag things, no matter how you try and get them to.

Making tagging content accessible - how do we make the tagging task appealing to the masses? PME - folders.... are there systems that lay people use to organize files that we can learn from such as folders and files? Incetivize the tagging task with rewards. Refer to BJ Fogg's presentation!

Posted by Ant at 04:31 PM | Comments (0)

March 29, 2005

IA Summit 2005 - BJ Fogg

Designing for Impact was the title of BJ Fogg's presentation about how working with technology changes the way our minds work. BJ wrote 'Persuasive Technology' These are the notes that I took from his inspiring keynote lecture.

With the digital age a new phenomenon is emerging where few people who design technology have the power to change the many who use it, quickly. Just as a ballerina's shoe deforms her feet over time, spending hours on end in an email program or browser also changes our minds.

Are we the 'Shaman' of the new age? As the crafter of digital tools we are changing the way people's minds work and culture at the same time. The desire to press "control z" in a car accident, like a ballerina's deformed feet are side effects of this cultural change.

Sometimes we can plan side effects (or just effects). Asking someone to introduce you in a particular way (e.g. "This is Anthony, he is an information architect with expertise in designing social software") has an impact on the course of the following events or discourse.

Users of software should not just 'drift through' an interactive experience. There should be a plan for the outcome of the user's experience. There should be a message behind every interface [Note: This is essentially brand experience design]

The way you design for a one time behavior change, is very different from that for changing behavior over time. People in small towns understand that their relationships with people are likely to be built on multiple interactions. This changes the way they behave compared to those in a big city where interactions are most likely to be 'one time'.

Persuasion as a trend appears to have coincided with the advent of the web. Machines can control human behavior. There are many good things you can do to persuade people, but there are a lot of bad things too.

How can technology persuade you to keep in touch with your family? How can it persuade you to go to the gym? The change in presidential candidate's websites between 2000 and 2004 was big. Employing some of the 60 (approx) theories about how to persuade people. Academics don't agree on the master of these techniques.

Companies embark on impact analysis whereby they graph their aspirations of their users (e.g. sign-up, pay etc) using axes of feasability vs importance (i.e. importance to business success). The top three of these form the primary goals of the company. Persuasion strategies such as praise; persistence; barrier reduction; immediate rewards; pain and fear; social influence; stories (cause and effect); hope (Lottery) are then utilized to see that the goals are met.

The Fire in Captology (what's hot in persuasion right now)

  • Video games - There is a recruiting tool by US army called 'US Army' that persuades people to sign up. Rehearsing behavior in video games influences what players do in real life. Video games are for rewards and are highly compelling, because players can feel their competency growing. Certain demographics get addicted to these games because they get positive feedback about growing competency that is lacking in their lives
  • Automated Behavior Modification (clicker training) is a classical conditioning technique often used to train dogs (click, then feed treat). It is Awkward Behavior Training (not rational). The idea is reinforce everything that is a positive with rewards. Computers can train users like clicker training for dogs and dolphins. When you do something the computer likes, it will reward you. Slot machines do this with periodic rewards in the form of payouts. Very powerful, very scary. Sounds to reinforce: Running water & harps are loved. Horns and alarms are hated. People hate sounds that sound like something bad is happening, like a baby crying.
  • Maxim for Credible Design. To increase the impact of a website, find what elements your target audience interprets most favorably and make those elements most prominent.
  • Companies will map the psychographic profile of users to demographics and will sell this to the highest bidder. They will measure this through observing user behavior.
  • Sequencing strategies work, such as asking for something big (plane ticket) followed by a small request (can you give me a few dollars). The small request will be granted when the larger is refused.

    Who we are as people is expressed through what we create. Methods do matter and we have a social responsibility when creating software.

BJ's Lessons learned
  • Specialize as narrowly as possible. The more you specialize, the broader the impact. This is a law of physics. Focussing on one area gives you more power in that area. Think of three ways you can specialize. In 40 hours, you can be the best in the world at (e.g. passwords of 14yr old japanese girls).
  • Take Risks. Find stories in your life where you overcame something big. These help you when things get tough.
  • Appreciate. Feeling appreciation is a very healthy emotion. Your heart and brain become synchronized. Most spiritual leaders preach this.
  • Rebound. When you fail, bounce. Just get up and keep going. The world keeps going, so you better get up. Walking is controlled falling. You have to fail to learn.
  • Allow yourself to be guided by principles and work with communities to help you make it there. working together we can achieve our goal.

Posted by Ant at 08:42 PM | Comments (1) | TrackBack

June 04, 2004

Site Mapping Tool

This looks useful...

Posted by Ant at 09:17 AM | Comments (0) | TrackBack

April 09, 2004

Interaction Desginers - Marc Rettig

Marc Rettig came to talk to the innaugural London meeting of a new group known simply as Interaction Designers a few weeks ago. He has a great case study on designing the interaction for a complex CAT (computerized axial tomography) scanning-cum-arterial-surgery-planning device. There was one tool he's developed for analysing the context surrounding task flow that looks particularly useful. It's well worth closer inspection and captures information about: Required Information; Required Knowledge; Potential Errors; Success Conditions; Barriers to Success; Cognitive Task; Ongoing Concerns for each task the application must facilitate. See it in his and Brian Herzfeldt's paper entitled 'Interaction design case: VasSol CANVAS' which can be found under the 'Project Case Study' section on Marc's site

The Interaction Designers mailing list has been a little quiet to date, but It's only a baby. The start of something purely for interaction design is a good thing, as there's a few communitites dedicated to Information Architecture that spill over into interaction issues as it pertains to information design. But, the wider field of interaction design that covers the physical world as well as the etherial, is better equipped to inspire those within this specific dicipline. Now to see if it can overcome Clay Shirky's Power Law

Marc's done a lot of work toward forming a syllabus for teaching interaction design at the Illinois Institute of Technologys Institute of Design. It's well documented on the AIGA site here. It's just the sort of inspiration we need here at 'The Corporation' in order to formulate our own interaction design training syllabus. I'd be grateful for any suggestions of areas to cover. What do people learning interaction design need to know most? What don't they absolutely have to know, but should?

Posted by Ant at 12:40 PM | Comments (0) | TrackBack

April 06, 2004

Topic Maps well explained

This Article by Lars Marius Garshol at Ontopia is very good and been well recieved by those on the sigia-l information architecture mailing list. Well worth a read if you want to start comparing Topic Maps with more traditional approaches to organising information.

Posted by Ant at 11:58 AM | Comments (0) | TrackBack

March 25, 2004

Mags - content IA

These are the notes Mags (Margaret Hanley) made for me during a mentoring session yesterday. I'm the kind of person who likes to have a structured approach to problem solving when I'm learning the art of doing something (that kata thing again) so this kind of 'step by step' way of thinking helps me. The content side of IA is currently the area of IA at which I'm weakest, so this is a good crib sheet to start my thinking process on the new project I'm taking on, known as 'The Creative Archive'.

Information Architecture Content and Classification

Content Analysis is about looking for patterns in content and templates. There are levels of analysis e.g page vs object.

Classification Analysis

Existing Class Schemes Write these down:
  • Metadata
  • Existing on the Page (English Regions project had Locations)

Subject Knowledge
Example Location Class Scheme

  1. Find:

  2. Compile Candidate Shemes
  3. Determine appropriate granularity of description (e.g. Village/Hamlet level, Postcode)
  4. Either Buy outright, Licence, License and Modify or Create the scheme from scratch

Content Objects

Think of a content object as the smallest amount of content placed into a content management system.
Each content object has attributes that define the structure of the object. For example:

Article Object may have

  • Title
  • Lead Paragraph
  • Body Text

Three Types of Metadata

1. Descriptive (aboutness) Controlled Vocabularies & Synonyms
  • Subject
  • Location
  • Audience
  • Proper Name
  • Programme/Brand
  • Historical time period
Keywords is more like freetext rather than >> meta name=subject content=automobiles, racing

2. Intrinsic Metadata
Stuff you can pull out from the file e.g.

  • File Name
  • Fomat/Media type
  • Bit Rate
  • Duration
  • Aspect Ratio

3. Administrative
CMS type information

  • Author
  • Time created
  • Version

This is all pretty Polar Bear kind of stuff, but the book doesn't put it quite so succinctly, probably because it may encourage people to take a 'one size fits all' approach.

Posted by Ant at 11:00 AM | Comments (0) | TrackBack

March 19, 2004

Making User Scenarios

What are Scenarios?
Scenarios are communication tools based on story telling. They enable us to communicate information architecture strategies and design concepts to an audience in a non-technical way. There are various kinds of scenarios: Conceptual Scenarios; Interaction Scenarios (includes Perfect Scenarios); Problem (usability) Scenarios.

When are they appropriate?
They can be used to sell a new idea or to illustrate a problem with a current proposition. Use them to sell the idea of a brand new concept through basing its use in a familiar context (e.g. Sally uses her new telly-phone on the bus on the way to school to watch her favourite cartoons). Or use them to illustrate the subtle differences of an improvement to an existing system (e.g. Sallys mobile has auto display and scrolling txt so that she can immediately see the text messages she frequently gets from her mate Jen. This is really handy in class when she cant be seen to be playing with her phone. One hands-free glance is enough for her to see what Jens said). They can also be appropriate for illustrating the impact of a usability flaw in an existing system.

What problems does this method solve?
Where it is difficult to convey the vision for an interaction or system, Scenarios enable us to communicate strategy and design concepts in the familiar format of a story. They add realism to abstract ideas through illustrating context of use. Scenarios are a great way to enthuse an audience about an idea.

They are also good for highlighting the severity of a problem when user testing is not feasible. This type of scenario is different from an expert evaluation because they place the problem in the context of how this affects the user (e.g. Sally didnt see the error message and was caught in an endless loop which frustrated her so that she bashed her keyboard and broke the F key).

At which internal audience are they aimed?
Scenarios are great for all internal audiences as they create a clear picture of a concept, problem or end goal. They are primarily used to communicate with non-technical folk because they do not involve abstract constructs such as information hierarchies or data models that tend to scare those who do not fully understand them.

What is the deliverable?
As is with most user experience design tools, Scenarios can take a number of forms. Essentially they are a story, so whether you use a comic book style, or a written account is a matter of preference, suitability for the primary audience and purpose. The best scenarios will incorporate some kind of representation of the protagonist, to allow the audience to associate better with the consumer of the product or feature you are illustrating with the scenario. Problem Scenarios should document how the system could be improved.

How can it help me design a solution?
Scenarios can act as a mission statement, or vision to which the team can work. They can hint directly at content, features, interactions and/or at a general feeling or experience. Problem Scenarios will directly outline the area of concern and its effects on the user.

Use Perfect Scenarios to outline the best way the system should be designed without the constraints of reality. This kind of extreme optimism makes a very useful starting point for conversation and brainstorming the best possible compromise. Use them in conjunction with Personas to really add weight to how your target audience could be or is currently using your product.

When do I use it in the development process?
They can be used throughout the understanding and conceptual development phases. Use Conceptual Scenarios before its too late for new ideas. Use Interaction scenarios as a basis for beginning work on Use Cases.
How many people are needed and from which disciplines?
They can be used throughout the understanding and conceptual development phases. If they are written, someone with a grasp of the English language and writing should do it. Good stories are written succinctly but touch on the essential points that illustrate the important areas of the concept. Sometimes its useful to accompany a written scenario with a storyboard, so someone who can visualise ideas is very helpful at these times. Whether you do this as a solitary exercise or a group session is up to you. Group sessions usually ensure better buy in, but less concise results. Do it with creative people who are open to the process. User empathy is a must for Problem Scenarios and someone who is in contact with users regularly can better visualise how users will react to usability flaws.

Method instructions

Time to do
Preparation: 5 mins to psyche yourself up, collect previous notes, relevant ideas in your head and find some paper and a pen. One hour to get markers, flipcharts and supporting material to set the scene for session participants and set an agenda.

Do: 1/4 4 hours each scenario depending on whether you bosh out a paragraph or run a facilitated group session and make pictures and stuff afterward.

How To
1. You will need to know the basic tasks a user requires of the system before you start. You can use Interviews, Contextual Inquiry, Ethnography or Task Analysis to inform you, or even just a great idea (just be sure it is truly *great* and not a magnificent wank). You also need to know the context in which users will use the product.

2. Describe as succinctly as possible the interaction that needs to take place. This can be fairly vague or it can be specific depending on the purpose of doing the scenario. Include references to cultural or attitudinal issues as this helps build context but only refer to technology where it poses a significant design constraint (e.g. Robert hates computers and has a Pentium 1 and 28k modem, therefore the internet is a slow, painful experience for him)

3. Write up the scenario in a format that can be shared. Spice it up with illustrations if you wish and where possible include a picture of the protagonist to help the audience visualise the story. Then distribute to the team.

Method tips

  • Make sure that the scenario includes how a user is accessing the product (environment), the feature you are trying to illustrate, how they use it and illustrates why its good or bad.
  • Make the story succinct and engaging. You need to hold the reader/viewers attention and capture their imagination.
  • Sometimes it is useful to include the emotional state of the protagonist.
  • Use Personas as the protagonist to verify that the feature or product satisfies the target audience. Do three or four scenarios per Persona.
  • As with Personas, it is important that the scenario is believable for maximum effectiveness. Make them at least a little messy, because life isnt perfect.

Common pitfalls

  • Dont try and convert the sceptics with a facilitated session, as their scepticism will throw you off and corrupt the believers.
  • Scenarios are too far-fetched and thus lose their impact.
  • Scenarios are too detailed, laborious or digress and therefore are not engaging

Related methods
Before: Personas, Task Analysis, Contextual Enquiry, Ethnography, Brainstorming
After: Architectural Diagrams, Flow Diagrams, Use Cases, Wireframes.

Posted by Ant at 05:19 PM | Comments (0) | TrackBack

March 03, 2004

Tips for designing task based interaction flow

We often get asked for advice based on stuff we've done. I get asked about designing online registration and authentication systems, because I spent a good chunk of my time at 'The Corporation' designing an equivalent to Microsoft's 'Passport'. This log entry captures some general pointers I mailed someone the other day.

  1. Always remember, nobody wants to do this. Its nothing but a pain in the backside theyd rather avoid. Forms are boring. Make sure the tone is polite and not overblown nor curt.
  2. Do not use jargon or insider terminology, this just adds frustration to the experience of the unenlightened majority participating.
  3. People dont trust this interweb thingy with their personal data. Theyre sure big brother can infiltrate it and come kidnap their kids. So, be transparent about how youre going to use the data and ensure that the system is secure and solid in behaviour (if it behaves "all flakey", youre not going to engender a sense of trust in the user). The Corporation's Single Sign On ensures users can get at and delete their data held by the The Corporation at any time after they sign in.
  4. Show progress (how much have I done, where am I now, how far have I got to go).
  5. Make the process visible in the interface (so you can see whats involved at a glance and it doesnt feel like youre going into a black hole never knowing when the end is nigh).
  6. Break the task into chunks (the perception of complexity is augmented by long forms and you can make long forms seem short if you break it into pages of bite-size sections... Its all psychological).
  7. Validate for correct data entry at the end of every chunk, not at the end of the process.
  8. Wherever possible make the process navigable back and forward so people can fill it out in whatever order they choose and explore whats coming up. This isnt always possible, but its an ideal to strive for.
  9. Provide lots of contextual help in the interface (any ambiguous terms should be accompanied by a Whats this? link)
  10. Be consistent in layout. People dont want to miss anything. If you have every widget in a consistent place, theyre less likely to miss something and get more frustrated when an error message appears.
  11. Wherever possible, break errors out onto a new page, so that it does not look like youve just come back to the same page after pressing next.
  12. Errors are usually not the fault of the user, but the fault of the system for not understanding the user or allowing them to input how they would naturally. Make error messages sound that way. This system is stupid and only understands one way of entering calendar dates... Sorry. Could you do it like this please: DDMMYYYY.
  13. Make the system forgiving. Allow people to enter info, play with widgets etc to work out what they do without forcing them to pay the consequences for their actions with irreversible process steps. This is about allowing learning through trial and error.
  14. Use widgets consistently and dont be weird with the interface. This is sensitive stuff. Make it predictable and safe feeling.
  15. Indicate direction of the task flow within or around buttons. Next should point to the right. Back to the left. Cancel shouldnt point anywhere but rather have a feeling of finality to it.
  16. Confirm when the process is complete with a closure page telling them what they can expect to happen next, or what they can do now theyve endured this painful process.
    Posted by Ant at 10:07 AM | Comments (1) | TrackBack

February 10, 2004

Nice Information Design

This is a nice peice of information design using flash to morph between 3 views of the same map. This is what I would catagorise as really appropriate use of this authoring tool (i.e. doing something that can't be done using html or an equally standard delivery language).

Dynamap This Flash-based demo attempts to capture elements of the Dynamap technology. Multiple layers of information become viewable as the substrate is rotated across the viewing angle. By scrolling the mouse vertically, users are able to mimic this effect.

Posted by Ant at 05:51 PM | Comments (0) | TrackBack

Screen Reader Simulator

I happened upon this site/app which can simulate how your website is interpreted by a screen reader for the visually impaired.

Screen Reader Simulation

Very useful!

Posted by Ant at 05:33 PM | Comments (0) | TrackBack

January 26, 2004

Modelling Languages

Today I have been researching modelling notation methods, inspired by a presentation I have to give on Friday reporting back on the ForUSE conference I attended last year. Helmut Windl made reference to a modelling language he referred to as 'K3' which incorporated the use of 'swim lanes' to differentiate between organisational units responsible for certain activities or processes within a overall system flow. I was keen to look into this further as it sounded interesting and relevant to the work I am involved with at the moment which has multiple staff (from varied organisational units) who use the same system to manage and produce products on The Corporation's website.

I ran into many publications (here) by Dr. Peter Rittgen which start to make the picture clearer, but not crystal just yet. Lots of good reading that should inform some kind of opinion, however.

Posted by Ant at 04:38 PM | Comments (0) | TrackBack

January 21, 2004

YAON Diagram Technique

This is pretty hardcore, but might be useful for something in the future, so I'm noting it down. YAON is a Static Diagram Technique for Object Oriented Distributed Systems. It's mainly used for notating systems with the intent of using Java to build them. It requires a little knowledge of Unified Modelling Language (UML) which is a part/tool of the Rational Unified Process (RUP)

Abstract: This report describes a practical notation designed to graphically document the implementation decisions embodied in object-oriented programs running in distributed systems and open networks using different communication protocols. The notation is based on ION [AI95] and UML [RAT97a] and captures the static aspects of Object-Oriented systems. It introduces some new concepts such as interfaces and final classes. It captures the essence of Java in a pictographical way.

The notation has been succesfully used to model real-life systems such as the live scoring system for the Compaq Grand Slam Cup 1997.

An automatic translation of models described in this notation to Java code is intended. The notation does not intend to be a graphic programming language but a design tool complementary to the Java code.

Posted by Ant at 12:38 PM | Comments (0) | TrackBack

January 16, 2004


Theory as far as I am concerned, then, is best understood as an emergent property of practice. Theories are in part post hoc rationalisationsthe plausible stories which we tell ourselves to account retrospectively for our actions.

If only I could explain myself with such impeccable clarity! This paper entitled Theory for Practice by David Sless shows that when somebody can explain a concept or set of concepts without relying on jargon or buzzwords, it is extremely powerful. This is because it demonstrates a full understanding; to the point where there are no holes in comprehension of the explanation of the presented concepts due to the use of the syntax of an exclusive club.

Aside from the writing style of this article, the concepts within are also so very pertinent to what I've been thinking/writing about with process and design theory. Not only does it suggest that rigid process isn't as valuable for solving problems as it is for teaching people how to solve problems, but it also articulates my feelings about moving from a linear way of working, to an 'inspect and adapt' or Agile mindset... and that's just a little bit of it. if this is 'Constructionism', I must find out more about it.

Abstract from the paper: This paper discusses a constructionist approach to information design and contrasts it with the more widely used constructivist approach. The paper suggests that there are five principles of information design: politics, position, parsimony, politeness, and performance. Of these, politeness is the most important.

Posted by Ant at 03:13 PM | Comments (0) | TrackBack

January 12, 2004

Faceted Classification: How-To

How to Make a Faceted Classification and Put It On the Web

Faceted classifications are increasingly common on the World Wide Web, especially on commercial web sites (Adkisson 2003). This is not surprising--facets are a natural way of organizing things. Many web designers have probably rediscovered them independently by asking, "What other ways would people want to view this data? What's another way to slice it?" A survey of the literature on applying facets on the web (Denton 2003) shows that librarians think it a good idea but are unsure how to do it, while the web people who are already doing it are often unaware of S.R. Ranganathan, the Classification Research Group, and the decades of history behind facets.

This paper will attempt to bridge the gap by giving procedures and advice on all the steps involved in making a faceted classification and putting it on the web. Web people will benefit by having a rigorous seven-step process to follow for creating faceted classifications, and librarians will benefit by understanding how to store such a classification on a computer and make it available on the web. The paper is meant for both webmasters and information architects who do not know a lot about library and information science, and librarians who do not know a lot about building databases and web sites. The classifications are meant for small or medium-sized sets of things, meant to go on public or private web sites, when there is a need to organize items for which no existing classification will do. It is certainly not the intent of this paper to show how to build another universal classification, nor to describe how a library that uses a faceted classification scheme can put their catalogue online.

Posted by Ant at 06:19 PM | Comments (0) | TrackBack

November 17, 2003

Visualising Information

Links to Information Visualisation things from Stamford university and Cybergeography's equivalent. This site also has lots of lush topics like 'Network Topology Maps' and 'Global Internet Diffusion'... ooer, don't that sound fancy?

Posted by Ant at 05:50 PM | Comments (0) | TrackBack

November 04, 2003

Faceted Classification article

This Article is about faceted classification... more specifically, Faceted Application of Subject Terminology.

Posted by Ant at 07:22 PM | Comments (0) | TrackBack

October 24, 2003

ForUSE - Making Usage More Productive - Lucy Lockwood

Raw Notes... added retrospectively. NB - Usage here refers to Usage Centred Design.

U-CD can dramatically increase productivity of users. We can measure this by how quick people can get in and start, through to error rates.

The primary tenet of U-CD is in understanding Users (Roles), Work (Tasks) and Needs (Tools). The aim is to look at how things are REALLY done and focus on key issues and immediate intentions. What's next?. Look at the purpose of actions in the larger context or workflow. Identify difficulties and how to deal with them.

A Usage Centred Design Approach encourages sound decision making based on realistic assessment of Priorities (business importance + user importance) and tradeoffs. It is business realistic.

Ranking user roles and task cases by frequency of use is key to deciding what is floated to the top level of the User Interface.

Task Case modeling is a powerful tool for Business Process Analysis and redesign. [Say it Sister... This is such a hard one for many to grasp. Design can, does and should inform business models and processes]. Use Task Case modeling to identify 'Technology Steps' or what user actions impact technological solutions.

User ROI. Is a feature worth having if it is too hard to use, too laborious or too hard to get to within an interface?

Design objectives

UI architecture should be easily understood by users, even beginners, after brief exposure or practice. [Learnability if not Usability]. Related information should be gathered about WHEN an interface is used.

WYSIWYN - What you see is what you NEED.

Task cases + User roles are re-usable - e.g. Help topics can be defined by them, test cases, acceptance tests... etc.

Help, whether in context or elsewhere should cover:

  • What is this?
  • How do I?
  • What should I do here?
  • What do you mean?
  • Tell me more!

Most external help entries should explain and support common extensions of:
..Show Me
....More Info please

Role Incumbants (this is Lockwood&Constantinese for the characteristics of people performing a certain role. Think Personas). These should bring with them measures of:

  • Proficency - distrubution of skill levels
  • Interaction - charateristic usage patterns
  • Information - communication characteristics

Operational Risks - What are the consequences of error, failur, misuse or delay associated with the application's role? Accuracy, confirmation, error handling, clarity are all to be proportionately well addressed according to operational risk.

Work Environment - Where will the application be used? Noise, Vibration, Lighting etc must all be considered.

Device Constraints - What devices will be used to access the application or information? Input devices (e.g. stylus or keyboard), displays etc must all be considered.

Structure - Be consistent with layout and graphic treatment of elements. Don't represent the same concept differently within the same interface or application.


Clustering task cases [This can really help to define what gets done within a sprint or iteration]. Group 'co-operating' task cases together either necessarily or optionally. Cluster toward more efficient interaction and simpler navigation. Visually distance, or seperate cases where co-operation is unlikely.

Conventional use case narratives are fully ordered. Sometimes in the real world these aren't intrinsically fixed. Thus, Flexible ordering should be supported and is preferrable.

Performance metrics: Performance measures directly evaluate actual usage. They can be based on a working system or a prototype. Task completion time, completion rate, percentage complete and correct, help requests, error rates and reworks are all considered when measuring the performance of an interface.

Measurement of an interface should be directly related to design goals.

Measuring the productivity ratio done through the calculation: Unproductive time subtracted from total time, divided by total time. Unproductive time is all time spent not directly working toward the goal (e.g. errors, help requests, delay in interpreting interface etc.)

All measurements of course, are only any good if there is a measure before and after the the change of which measurement is desired.

Posted by Ant at 11:16 PM | Comments (0) | TrackBack

October 22, 2003

ForUSE Debate: Patterns or Process Constantine and Lockwood

Debate: Patterns or Process? What works for Usage Centred Design? Lucy Lockwood (process) vs Larry Constantine (patterns).

Patterns are a way to capture the wisdom of many years of design experience. They help to expand and extend the awareness of the experienced designer and aid to save the inexperienced designer. Or are they just a poor, inefficient substitute for well implemented process.

For Patterns Larry Constantine
A pattern is an idea that is useful in one practical context and probably be useful in others. Patterns describe repeated problems along with effective solutions in a standardised useful form. Variations may included name, description of problem, applicability of pattern, solutions, consequences results. Some are just Thou Shalts... or shalt nots.

Welie patterns are some well known and often used patterns. They are a bit "Like, duh" though. Patterns can be from ways to display tables with alternating colours in the rows, to the metaphor of a shopping cart. Good patterns through, capture best practices gained through experience. Patterns describe simple and elegant solutions to problems and capture solutions that have developed and evolved over time. hence they aren't the designs people tend to generate initially,. they reflect untold redesign, as developers have struggled design patterns capture these solutions in a succinct and easily applied form. Design Patterns Addison-Wesley, 1995

Best practice patterns should be Non obvious or even counter intuitive. Broad but specific application. Clearly spell out problem to be solved. Clearly articulate solution and tradeoffs. Exemplify best practices. Basically they are the subtleties within the obvious patterns. The should be based on substantial substantiated patterns.

Against Patterns Lucy Lockwood.
UI design is still at the arts and crafts stage. Early civil engineering and architecture was mostly learned by apprenticeship. They copied what they had seen that worked. Very limited number of 3rd degree wizards. The development of engineering principles and processes allowed for expansion of engineering corps. There is no one size fits all yet, because there just isn't the depth of knowledge to be able to say "This worked here in exactly this situation, so it will work here". Patterns still rely on the '3rd degree wizard' to be able to make best practice. Process allows those who aren't '3rd degree wizards' to work within a framework to achieve best practice.

Practicing designers need help recognising problems and poor design... concrete principles, not cognitive psychology. They need direction for improvements, practical guidance, not canned solutions. There is no such thing as "UI standards". Patterns also only cover 10 - 20% of problems. they are often misapplied. The DO NOT support creativity or innovation.

Who Captures and maintains patterns? A company wants designers to design, not waste time capturing and maintaining patterns and they won't pay for a designer to do this. How do we decide what's a good pattern. It's totally subjective. How do we know that the pattern we have is the best pattern that can be trusted? If a pattern written to be timeless it is too abstract and vague. Description is so general that it doesn't offer specific guidance. Patterns are too tied to current technology and fashion or a particular context.

Where do you find patterns? How do you know which pattern you need? They assume that the designer has analysed the problem well enough to choose a suitable pattern. Patterns can compound a problem that wasn't adequately solved in the inception of the pattern.

[Thought: Competitor analysis is really about gathering patterns...]

Five general rules of usability that patterns are trying to achieve....
Access: make the system usable without help of of instruction.
Efficacy: Don't interfere with those who know it already.
Progression: Facilitate knowledge advancement
Support: Support the real work users are trying to accomplish.
Context: Suit the system to conditions and environment.
Basic Usability principles: Visibility, Feedback, Structure (layout dictated by meaning and use), Reuse (use interface components and behaviors consistently), Tolerance (forgive mistakes), Simplicity.

Posted by Ant at 02:39 PM | Comments (0) | TrackBack

ForUSE The Agile Customer's Toolkit Tom Poppendieck

Raw Notes...

Most books and publications about XP and agile are very programmer oriented. There's no place for requirements analysis, UI, or interaction design.

Writing effective use cases

Tools for Customer side practices:
Decision Tools (how to decide what to do)
Role tools (how to organise work and team)
Interface tools.
Story telling and customer tools

Effective collaboration is based on shared
Values Implicit belief system, vision, or mental model about desired business reality or purpose.
Principles Guiding ideas, insights and rules for deciding.
Practices. What do Do, Actionable.

Manufacturing metaphors for software development don't work because if you talk to manufacturers and engineers, every time something is built, the process is different and unique. Toyota will stop at every stage of the manufacturing process and test whether it is actually works.

Lean Principles... Tool 1.

Eliminate Waste Basically, this is just be effective. Weed out the parts of process which are not.
Amplify Learning This is what iteration is all about. Learning is more important than the code itself.
Decide as late as possible By waiting, you get more information and feedback
Deliver as fast as possible if you are going to wait, you have to deliver fast.
Empower the team agile processes focus on people. Complexity means working together... as effectively as possible. Let the team figure out how to do their job, because they live and breath it and will obviously work out the easiest and most efficient way for them. It will also make them happier.
Build integrity
See the WHOLE It is more valuable to measure the effectiveness as a whole, rather than the individuals effectiveness. The team means that everyone is accountable. Rewards should be given to the team, not to individuals within a team.

Concurrent Development... Tool 2

Why are we doing this? What needs to be done? How do we build it? all happen concurrently. Information is done in such a way that you hand over requirements at increasing levels of detail as the project proceeds.

What do we do first? Breadth or Depth? Both. Breadth: Low detail system intent and release and iteration planning. Depth: most important features first. Working app every iteration.

Doing most valuable first is more important than doing most risky... [what is value?]. Build by feature - order by ROI. Defer commitment. Simplicity, feedback, let subsystems and frameworks emerge. Value learning over code. REal customer needs, re-planning and re-factoring are not rework.

Chartering... Tool 4
I don't know why he skipped over tool 3... something about a chair with legs.

Chartering. A team is a community and needs a purpose to exist. Individuals contribute differently. Customers > business goals. Testers > Quality Goals. Interface designer > usage goals. Developers > architecture goals. Analysis > domain goals. A common understanding of purpose is required so all understand the mission. Define success, frame boundaries, facilitate information flow. Align decisions. Mission statement or elevator pitch. Objectives outlining purpose of the project and what it's about. Committed resources. Who defines the success? What is important? What is success? scope? Schedule? defects? resources? You should be able to express all aspects of your mission on one page. If you can't say it concisely, you don't understand it.

XP Practices... Tool 5

Customer Practices: Release and iteration planning. Frequent small releases. Customer tests. Story telling. UI Model. Essential Use Case model...
Developer Practices are the Engine.

Agile Development cycles. Release planning is all about breadth. Iteration planning is a mixture of depth and breadth. Implementation planning is all about depth.

User Stories... Tool 6

Often confused with Use Cases. Stories cover everything the user cares about, both functional and non-functional.Story Card content: Title, One or a few sentences describing what is wanted written by the customer. Developer estimate of relative cost. Sample tests sketched on the back. It's a hand Written index card which has a tactile advantage. Low inhibitions to throw away. Used for sorting, allocating and tracking. The card is not everything though. You needed card, conversation and confirmations. The value is in talking about it, not in documenting it... [hmm, I can see a few probs here from my experience]. Story sizes are determined by implementation effort. They should amount to two to five pair days.

Stories enable FLOW... Velocity can be gauged through being able to assessing history of iterations and assessing burn rate. This means this can establish reliability.

Tom advocates that the end users, UI designers, UC designers, Subject matter experts, Testers and analysts, process and product owners define the right stories and the right tests to then feed requirements to the developers... [This is really quite similar an approach to staggering work that I was writing about a week ago or so]

Domain Language... Tool 7

Find the right words. A glossary of domain language will save a lot of pain and arguments between the team.Effective communication depends on a shared language. EVERYONE must have a common understanding of what is what. A domain should be what the software is about. Domain concepts are what the system shows, knows and remembers. Stories, conversations, customer tests, and code should use domain language. The customer already knows it, though they may not always use it precisely. The language must be rich enough to capture business concepts, rules and relationships. Domain concepts will usually make an appearance on the interface too. It should be directly implemented in code... [lovely gem! It would be worth doing research into the language of the audience too I would say. This would make this even more powerful]. You should iterate this language too. It should be defined in the same way as you would plan doing XP... work on breadth and depth at the same time. Language extends to informal UML, digital photos. class diagrams, interaction diagrams, state diagrams. Make them quick and disposable. [oops... we've been too detailed in this area and spent too much time doing beautiful flow diagrams, thus making it set in stone on some level. They didn't facilitate throwing away and starting again. Makes me think we should come up with a velcro-backed kit or something for making dynamic easily reworkable flow diagrams or something... that would be cool!]

Essential Use Cases... Tool 9
yup, he skipped a whole bunch more. Will ask about that later.

What people use the system to do. Business process workflow. A use case is about a business goal. Steps to reach the goal. User intent steps. System responsibility steps. Use cases implement some part of a workflow. Effective use cases are lean. Most write too much. Use conversation and tests to define details. A use case is a users steps to achieve a goal. A story is a unit of developer work. Don't mix them up.

Alistair Coburn - Writing Effective Use Cases. - buy it. Essential use cases are really brief! like REALLY brief enough to fit on a palm card.

Value to use cases should come from the frequency of use. However, make sure that their not subgoals... as in something that must be done to achieve something else. Prioritise according to value... Now he's going very fast through really good stuff and my brain is tired after a long day. I have slides, so will have to try and fill in the gaps later.

Interface Model... Tool 10

Organise tasks, paper prototype, refine prototype, define tests... eaarrrragghhh!! oh dear, brain has ceased to function all together now. :-(

Tom Poppendieck

Posted by Ant at 12:45 AM | Comments (0) | TrackBack

October 21, 2003

ForUSE Designing for Performance Helmut Windl

Designing for Performance - Helmut Windl - Siemens (automations and drives)

... Notes are a little more raw than usual, but the content is quite exciting if anything can be gleaned from these scribblings.

Electronic Performance Support Systems (EPSS) with Usage Centred Design (U-CD) N.B. this is NOT the same as User Centred Design (UCD).

EPSS Workflow and tasks are all visible in the interface. software applications that have an explicit goal for supporting work performance and thinking by people who know neither the work nor the software while accomplishing expert

Performance centred design is driven by user performance, whereas U-CD focuses on usage and improved tools supporting task accomplishment. Performance centred design is still a philosophy. There is no explicit process but utilises lots of other processes to inform design.

To design fro use you need to understand your users, their work, and their needs.
Users > Roles : Separate user actors from system actors then model roles. User actor play in relation to system
Work > Tasks : Identify Tasks needed to support user roles, cluster tasks by use and meaning, define intentions and responsibilities for each
Needs > Tools and Materials : Model UI contents needed to support task clusters. Derive visual and interaction design from models.

Product definition with product framework, user profiles, features and functions to roles to tasks to contents to implementation model. Also Creative design such as aesthetics. U-CD can be used at any size project from an agile one, to a big bloated process.

Performance Centred
Process simplification, reducing complexity and number of steps etc
Performance Information: All necessary information necessary to perform a task is provided in context.
Decision Support. Helps employee depending on work situation and condition to do the next appropriate steeps.

U-CD task model is currently unable to represent sequences of tasks and conditional branches visually in a model.

To redesign and simplify work flow, we have to capture and understand the clients real work process. This includes events leading up to and after the task itself.

K3 modeling techniques: like contextual design for capturing work process. [must find out more - looks good]. Designed to collect and represent real world work processes in an easy to understand model collaboratively with users. K3-Diagrams of the inspected work processes are drawn during field studies and are generalised to universally valid k3 diagrams that directly feed user role and talk modeling. Foltz, Killich, Wolf, 2000

K3 Notation
Activities represent related tasks supporting a high level goal e.g. cut, copy paste... represented by rounded rectangles. Control flows connect activities to indicate the sequence. Sequences are enclosed in start and end state. [This is quite similar to the way I would advocate modeling flowmaps which are heavily influenced by Jesse James Garret's visual vocab]. "Swim Lanes" [This is a really nice enhancement] allocate activities to personas, user roles or organisational units. Decisions by a user role or person are indicated by a diamond... etc

Much of U-CD doesn't enable flows in a visual way. So melding this with K-3 notation, you can get the Task Flow Map. I'm not going to make notes on this because it's too interesting to be distracted... besides which it's visual and my thousand words won't justify these lovely diagrams!

Exploratory Modeling [my thoughts] gather questions about a task case or user roles through taking a first attempt based on personas and educated guesses. Then validate these through interviews and contextual enquiry.


Posted by Ant at 04:50 PM | Comments (0) | TrackBack

ForUSE - Panel Discussion Between Extreme and Unified

Between Extreme and Unified: Where are the Users and Usability in Development Processes? - Panel. Ivar Jacombson, Jim Heumann, Ron Jeffries, Jeff Patton, Larry Constantine.

Jeff Says... Interaction designers make great Extreme Programming customers. Don't design up front. Quote "You keep using that word [design]... I do not think that means what you think it means..." You can't design without having an integrated, multidisciplinary design approach. We're talking about very Thick design from surface down to data level. One persons design is another's requirements. Do as much design as is necessary to proceed to that next step in development...

Ron Says... All software development methodologies are based on fear... Kent Beck. Fear from customers, fear from management. Programmers using XP are not predisposed to any particular order of doing things. They will however need to reshuffle things if some requirements are bought to an iteration. One in for one out. You will get things on time.

Jim Says... Usability into Rational Unified Process. Users are in the centre of RUP (based on use cases) Actors in a business use case model to define what the value to use cases to certain actors within the business. Usability comes in at the business level and the interface level. Use Cases need to be at the right level so as not to constrain the creative team and not to let them go too wild. Write the right use cases. Write the use cases right. Write the right system. Write the system right.... nnk...

Ivar says... We essentially agree. To be successful in the Software industry, we must raise the level of competence in our teams. Tools are going to get better and better in time as they develop. We need knowledge as an industry captured as best practices. These are not only best practices for designers but also for managers. We need to develop a process for the complete product life cycle.

Processional March question to Jim and Ivar. Give one example of a project that followed RUP correctly but failed? ... no answer
Same Question to Jeff and Ron about XP. "Everything seemed to keep going fine, customers were literate, process was working well and the quality and usability was high. But the client hadn't listened to their users adequately so the product ultimately failed.

What people are best suited for XP? People who will take on any task and focus on getting a good result for the team. The team works best when the team works together. We want people who are good at what they do and not hide behind a process.

What people are best suited for RUP? There are no specific kind of people that are necessary for RUP. RUP is about establishing a common language so that communication can be facilitated. You want people who are also good at what they do. You also want people who are diverse in skills so that they can empathise with other members of the team.

What kind of project product is XP best at? The best kind is a project that has a finite amount of time with mainly low risk as far as human life is concerned.

What kind are ill suited to XP? Organisations that don't hold the values sympathetic to all agile processes cannot make Agile processes work.

What kind of project is RUP best at? RUP wasn't originally designed as a management process. It was designed to help people know what a good way to do 'x' or practice actually looks like. RUP was designed was made through analysing what was common across lots of projects. RUP is a framework of knowledge, not a specific process. You can apply it to web development to military applications. It can be big or small. It's been going on for 25 years. It is designed to be specialised or customised, not a one size fits all.

To the best of your knowledge, what % of RUP adopters actually do it right, instead of just bought the software and been to classes: About 20%

And XP? The number is increasing, but we would guess a smallish percentage.

What if anything, does XP offer to help the overall visual architecture or organisation of the user interface? Nothing. XP is very much about making good code. it's up to the customer to specify the UI.

And RUP? Through creating a user experience model that is derived through the use cases. Representing flows and flow maps to show how screens fit together. There are specialists on a RUP team dedicated to making a good UI.

Can UML be used as a tool to communicate with XP teams? But of course! One of UML's strengths is aiding in collaboration... XP people say that not many people actually know how to use UML properly. Its a very specific language that is very specific. It is a good tool to know, but you shouldn't rely on it as a communication protocol.

In XP, is the role of Customer responsibility a confusion of expertise? Can a customer specify a good user interface? "Well, it's up to the customer". Jeff says, you can't expect a customer to design something if they're not qualified to do so. It comes back to common sense... use your head. Can your customer specify a user interface? If they can't, then perhaps you need to accommodate them with someone who can realise what they want in the form of an interaction designer.

Posted by Ant at 03:07 PM | Comments (0) | TrackBack

October 20, 2003

ForUSE - Instructive Interaction - Larry Constantine

Instructive Interaction: Innovating without Inundating Users Larry Constantine.

Raw Notes...

Talking about what users are used to. Based on premise that users can't tell you what they need, but only what they don't like.

Instructive interaction - Help systems as a start. Help systems are often not really very helpful. Finding the help you need takes too long and you lose track of the task at hand. Result is that help is under used and therefore software companies under invest in it because they've figures saying nobody uses it.

Putting help into the interface... or 'instructive interaction' - this is starting to sound a lot like the work we've already done in Single Sign On - where the user interface is self-teaching.

Learning usually requires being told, by being shown or by doing over and over again. Most learning requires repetition and trial and error. Exceptions are 'prepared learning' (single trial learning or Anticipatory learning... the 'oh, I knew that' effect). User encounters a novel or unfamiliar feature, and guesses what it does or how it works, then tries it and is finally rewarded by discovery that they were right. 1) Recognition, 2) Anticipation, 3) Action, 4) Confirmation. [this is kind of like defining 'learnability'] Interface should provide all needed help. Interface has to be 1) explorable 2) intuitable 3) predictable 4) have intrinsic guidance.

Instructive interaction is not about the system trying to do things for the users over the users doing it themselves. It's not about artificial intelligence. It's about making something consistent and learnable like a tool - a hammer. User Agents are also NOT good instructive interaction tools as they're more annoying than useful over time.

Explorable interfaces have no penalties for playing or trying things. Allow users to get out of a situation easily, so that it's forgiving. Consistent, safe cancel and rollback. Infinite level undo and redo is also very good (as in at least 12) even in web applications! (big oops on SSO). Beginners love menus because they allow you to see where you are and how you got there. Nested dialogues are the opposite of this as they obscure views of the previous path.

The user's best guess is probably right [this feels really right to me. I'm always wanting to do lots of 'expectation measuring' within user tests... ask a user what they think will happen by doing a thing, before letting them do a thing]. Windows are like different rooms, you better have a good reason to send a user to another room Cooper. Contextual help and feedback should be intrinsic to the appearance and behavior of objects, rather than something that's added on to them. It's not so much about MESSAGES, but giving feedback through the behavior of a certain object when manipulated.

Consistency of UI appearance, behavior, and organisation are all important. Behavioral consistency over consistent appearance. Predictability most important of all. Affordances, are as always, very important to learnable interface. Static visual affordances are VERY important, as they're always available to the user even when not actively using. Tooltips, balloon help, starting point highlighted, workflow line (draws the eye from one place to another), etc.

Balloon help - answer 'what is this?' 'what can I do?' 'what should I do?' Cascade screen tips to add more information than just the name of a tool. Link it to the right article in the help section. "Progressive Screen Tips"... make sure you can allow for it to be turned off.

Progressive enabling and disclosure unobtrusively walk users through a series of actions... wizards don't help skill building because you're still making it into magic rather than teaching the user to do something using the interface.

Anticipatory Action system tries to guess most common action such as highlighting an option within a dropdown list. Especially for a new concept in a UI you would have the item open/active the first time they come to the interface.

Implicit antecedents... avoid rigid logic or imposed order... don't think like a programmer... skip steps to anticipate what the user really wanted to do (e.g. radio buttons auto select on accompanying value fields being filled out)

Sometimes you need to animate certain interactions in order to have a concept make sense. Sometimes you just can't write out long-hand description of something you can illustrate really clearly with a clear, even stop frame animation.

Sometimes, standard, well established icons and visual elements/interaction idioms can be used in new ways. The key is to test and see whether you've bent the rules too much.

This kind of reminds me of previous lessons in music... "Practice doesn't make perfect... PERFECT practice makes perfect" Learning has to be done right, and anything you can do to aid users in getting it right the first time, the better off your they will be and the quicker they will know your design.

Larry Constantine

Posted by Ant at 09:49 PM | Comments (2) | TrackBack

ForUSE - Jeff Patton

Usage Centred design in Extreme programming and agile development environments

Raw Notes...

Agile software development isn't anything new. Books so far (since 1971) have discussed the psychology of teams and programmers within them.

  • Scrum
  • Peopleware
  • Dynamic Systems Development Methodology
  • Crystal Methodologies
  • Feature Driven Development
  • Adaptive Software
  • Extreme Programming

Born of financial need to make things quicker... meeeting of 17 people at Snowbird, Utah, 2001 formed 'the Agile Alliance'. 4 core principles of the Agile Alliance.

  • Individuals and Interactions over Processes and Tools (within the business)
  • Working Software over Comprehensive Documentation
  • Customer Collaboration over Contract Negotiation
  • Responding to change over following a plan.

There are other additional statements are also important and can be found at The Agile Alliance website.

Agile, like UCD is an approach to a method, not a method itself. Releases are composed of Increments which deal with making features. Release Cycle: plan release, feature list, evaluate release. Increment Cycle: Plan increment, determine feature list, evaluate increment. Feature cycle: Design Feature, develop feature, evaluate feature.

Less emphasis on artifacts, up-front design but more on customers and end-user collaboration and emphasis on day to day collaboration within the development team. Incremental improvement resulting in WORKING and USABLE software. Feedback using iterations.

Interesting XP points. Simplicity in design, test driven development, collective ownership, coding standards, System Design Metaphors, Frequent small releases, Customer acceptance testing.

Injecting UCD into XP - Release: Reconcile Roles and Goals with tasks then features. Role and task determine feature priority. Role and Task information drive feature design. Use feature priority and cost to find scope cutting opportunities. Increment: Role and talks information determine bug criticality. Feature: Role and Task information Drive feature design. Test using use cases assuming a user role.

Understanding the Domain. Contextual design work, taking photos of your end users, hear from them and their managers and other stakeholders. All the team needs to be across the end users.

Tactile collaboration tools and techniques - all your typical post-it note jockey stuff. Food, and Kitchen timer is helpful. Means motive and opportunity (as a way to get people involved in collaborative working. Basically, make it easy for them to do so). Make it fun and quick paced.

Accuracy and Detail aren't the same thing. Focus should be on Accuracy to begin with. Detail can come later... [ this really suits my 'Cut but Cut' thoughts ]. A conversation is better than a document. A poster is better than a document (they're like radiators of information - nice metaphor!). Avoid literal UI renderings.

Must get Alistair Cockburn (Humans and Technology inc.) Book.

Use Focal roles and focal task cases to drive priority. Relax standards on the unimportant features. Special attention to quality on quality for focal roles and tasks.

Detailed design comes in where necessary... as in later on. Write essential use cases, build abstract UI prototypes, Render wireframe UI, Validate through testing.

Agile is great because it allows for the mistakes YOU WILL make. The penalties are less because of the iterative nature of the process.

There are problems, but they mainly come from team issues. People not wanting to change or being freaked out by being out of their comfort zone.

Collaboration plan - contract between customer and design/development team.

Jeff Patten

Posted by Ant at 07:37 PM | Comments (0) | TrackBack

ForUSE - Designing for Breakthroughs in User Performance Gennine Strope

More raw notes...

Case study in Usage Centred Design meets Agile in making management software for nurses.

Brainstorm User Roles
Mapping roles
Brainstorming tasks
Prioritising tasks

Some mistakes made where profiling wasn't thorough enough and goal directed design wasn't thought through well enough. These guys had something like 20 'severity 1' usability flaws still, after 20 sets of user tests. No design lead time, straight into engineering. This is supposed to be selling us on XP and Usage centred design and so far I'm feeling like it's telling us that if you measure success by user comprehension and understanding, this just didn't stack up well. However, she's touting this as having shaved 4-6 hours on training nurses on the old system. But cripes! What must their old system have been like?

Lots of people say small design teams are best... so does she. Basically advocates contextual design. Keep statistics! (good, something new... I was scared there'd be nothing to think about from this) proof of the progress within the business. Return on Investment must be measured for justifying to management.

She's got a 'pocketfull of wisdom!' omigod, that's slightly nauseating... as is the powerpoint sound effects.

Posted by Ant at 04:54 PM | Comments (0) | TrackBack

October 17, 2003

Kids Interaction Design

Finding Noobie over at CuriousLee. Lovely ideas around interaction design for Children.

That kids, guided by adult experts, can design technologies for the future, was not necessarily what left me most impressed during my tour of the lab. In this organized playland, scientific method accommodates the laughter of children at play to produce tools that offer delight before utility

Thanks Matt!

Posted by Ant at 05:09 PM | Comments (0) | TrackBack

October 13, 2003


On Friday I attended a SCRUM course given by Ken Schwaber, who's brainchild is the SCRUM process (agile software development). A two day course crammed into one was a little hard to absorb, but nonetheless a great opportunity to pick the man's brains about his process.

OK, here are the basic tennets that I had mostly already grasped.

  • SCRUM is and Iterative process (inspect and adapt) good at isolating teams from 'seagull management'. Each iteration is about 30 days and no one is allowed to come and feed more requirements or changes to existing ones within that window (known as a sprint). This is regulated by the 'Scrum Master'.
  • The team meets every day at a given time and place to discuss three things. Each person reports i) What was achieved yesterday ii) what will be worked on today iii) what obstacles stand in the way of getting this done.
  • Requirements fed to team on a basis of 'Best defined, riskiest and business critical first' meaning, those requirements which are known and whose solutions are clearly understood are prioritised before those less defined. Those features which are deemed to have the most risk and or business value (balance of business benefit and user benefit) are also prioritised higher than those which do not.
  • Focus on Return on Investment.
  • Minimal reporting

Things that I had very much clarified were:
  • SCRUM basically has a premise that you can't just hand over a brief or spec, as this flys in the face of the iterative cycle where a multidisciplinary team cracks on with finding solutions to individual requirements rather than defining whole systems (yes, I was worried here... but I'll explain further, it's not that bad). Basically, Ken used the example of a flock of geese which use an empirical process to find what they need when migrating. Their requirements are that they need somewhere that's warm and has enough food and water for the winter. It doesn't matter where they go, so long as these fundamental requirements are met, the geese are happy.
  • The other revelation was that SCRUM can be used on anything from planning a party to building software. The premise is a tight knit multidisciplinary team. Meaning we have design, production, tech, editorial all working together at the same time solving about the same set of requirements in a sprint as each other... and talking lots. So, this allayed my fears that SCRUM was all about clients talking to technicians and design is left out of the equasion.

So, here's the tricky part. Alan Cooper staunchly argues that you can't design a good system as a set of answers to requirements. You need to be able to specify an entire system and it's dependencies if you are to succeed in making a well-designed system. Now, I agree mostly with this but am willing to experiment with the rigidity of this assertion purely because it just is not economical having your techs sitting around answering your odd question as you spend months designing a system that you're reasonably sure, but not definately sure will work. Or, would I argue, is it a good way to build happy and thus productive teams.

There will always be a need to do some preliminary research up front when we're talking about user research and defining requirements where you can't involve all team members 100%. Just like as a user experience designer, I can't code lines of code when the time comes to that. So ultimately when we divide a project into Understand, Concept and Design phases, it defines time periods where different skillsets are 'at the fore'.


So whilst in the understand phase, the best thing to do is to employ techs to do research into technical thing. If we see the research as a requirement just like a feature would be we can start to see where a scrum methodology can be employed. The biggest hurdle is convincing programmers that they're not wasting time by being involved in such 'airy fairy nonsense' such as research.

It's always been in the conceptual development phase that things have become hairy or clouded for me. It just never seems right to try and define a system in a slight vaccume (after all, techs can answer our questions, but they too have to estimate the complexity of things from time to time) and the tech team gets (rightly) pissed off waiting for the design team to give them a spec. Here's a thought. What if we were to design in a series of cuts whereby we define a 'sketch' of the overall system first (based of course on the research we carried out in the understand phase), then start to refine it feature by feature once we had some idea what elements would affect other elements. Thereby actually working side by side with techs to constantly flex and change the implementation according to what was achievable or desirable.

So, probably, and I say probably because I haven't tried this yet, it would look something like this.


Basic prototyping has proven to be the most effective form of documentation for communicating functionality to a technical team. A basic interactive wireframe made using Macromedia Flash speaks 1000 times quicker than a UML use-case which arguably takes about as long to write once you've wireframed it and analysed all the permutations of an interaction element. I see this as the way forward, in combination with some UML elements such as flows for specifying the way a system works and how the interface impacts it.

There's so much more to write here... but it's late and my concentration is failing.

Posted by Ant at 12:01 AM | Comments (2) | TrackBack

October 09, 2003

IDEO Method Cards

Ideo's Method Cards are a cool way to communicate design and IA methods to your team and clients. Similar to the ToolKit I'm trying to develop internally here at The Corporation at the moment.

See Also - The Creative WhackPack for more general creativity tools.

Posted by Ant at 10:28 AM | Comments (0) | TrackBack

Information Architecture - overview

Information Architecture.

This lesson has provided information about various ideas associated with the term "information architecture" and has endeavored to show you how information architecture is closely related to, and embodies most of, the long-standing principles of library and information science.

Posted by Ant at 10:24 AM | Comments (0) | TrackBack

October 08, 2003

A City is a brain, not a computer

Paper entitled The Information Architecture of Cities. By L. Andrew Coward and Nikos A. Salingaros.

"This paper argues that a city works less like an electronic computer, and more like the human brain. As a functionally complex system, it heuristically defines its own functionality by changing connections so as to optimize how components interact. An effective city will be one with a system architecture that can respond to changing conditions. This analysis shifts the focus of understanding cities from their physical structure to the flow of information"

Posted by Ant at 04:09 PM | Comments (0) | TrackBack

Digital TV usability

Matt Jones found this usability rap-on-knuckles report about digital TV. Not surprisingly disparaging as DTV is a bitch to use and probably always will be until someone re-invents the square-peg-in-a-round-hole remote control unit.

Like the first computer interface was just a keyboard a hangover from the analogue typewriter, the Digital TV remote is trying to take an interface for changing channels and volume into a controller for a basic computer... there's a comment on the linked page that says this better.

Posted by Ant at 01:35 PM | Comments (0) | TrackBack

October 07, 2003

A piano's lesson... interface confuses information.

Today I am the proud owner of a new Korg SP200 digital piano! I've been playing it a bit today and it's a real joy. Having grown up with a piano in the house as a kid, I have missed having one around to just plunk away at for relaxation.

Although the piano is not my first instrument, it's definately the one that I find the easiest to communicate with. It's to do with having all that visual feedback from the keys whereas with a saxophone or guitar, you just don't get that. You can see what you're pressing and then associate this action with the result it produces a sound.

The interface with a piano has direct mapping too there's no dual functioned keys. One key does pretty much one thing 'affords' pressing. So, as a teaching aid, it is far superior to most any other instrument because you can visually see the structure of chords and melodies.

The downside to this is making a connection between the visual patterns learned on the keyboard and those one must learn to read musical notation on paper. These are unfortunately not the same. When there are no learned visual patterns within the interface (such as with the saxophone, because you can't see the keys when you're playing), the patterns within music notation can be more easily 'learned by route' and translated into actions made by the fingers.

Music notation isn't just any old information though... or perhaps it is... It's a whole language in itself comprising letters, numbers, punctutation, sentences, phrases and more. So learning this language is less difficult when you don't have to cope with visual feedback too... or is it? Imagine being able to see how your mouth makes sentences when you're trying to learn a language. Is there an instance where visual feedback isn't necessarily a good thing? I don't know. I fear I've flown up my own backside here.

Posted by Ant at 11:37 PM | Comments (3) | TrackBack

October 02, 2003

New Title

At a meeting today where we saw some very cool Navahedron stuff by Nascent Form which I'll be writing more about at a later date (not so much the whizzy 3d navigation models, but more the information architecture behind them), Andy Tedd coined a term that I will now use in referring to what I do. You can call me a 'Senior Post-it Note Jockey'... lol...

Posted by Ant at 06:21 PM | Comments (0) | TrackBack

September 26, 2003

Links a plenty


Ooer! Wired article "The SenSay cellular phone, still in prototype stage, keeps tabs on e-mails sent, phone calls made and the user's location. The phone also adapts to the user's environment."

RFID more privacy and identity issues here... Radio Frequency Identification - tag items with a radio chip the size of a pin head.

IA, ID & Graphic Design

Useful IA and Design Resources for sorting out work practices and process.

Deciding which usability test method to use. Nice overview of different usability methods

Found Gold on colour theory and international interpretations of it in design. Colour Matters, Symbolism of Color in different cultures. Also, Colorcom colour consultants.


The trouble with out of the Box thinking article on Ubiquity magazine site.


Grays Anatomy Online. I always loved the book, now it's online.
Posted by Ant at 11:40 AM | Comments (0) | TrackBack

September 22, 2003

Tim Berners-Lee

Went to a lecture at The Royal Society given by Tim Berners-Lee this evening. He made some interesting points in a frenetic and charasmatic style. The main thing I took away was that his initial vision of the web was bourne of the requirements for a document control and sharing protocol. A founding principle of this was independence from software or hardware platform, network accessibility, application, language, culture, disability... and so on.

"To seperate content from form is good design." was one statement that I've heard before, but rarely has it had as much resonance as when put in context of the lofty goals of what the architects of the web set out to achieve. The standards laid out by WC3 have been a little lost on me in my more ignorant past. Over time I have realised that the standard is our friend and to deny it for aesthetics, economy or perceived flexibility, is short sighted.

Tim Berners-Lee made me realise that web ubiquity will only be achieved through a combination of standards and goal directed design. This is what will lead us to his vision of The Semantic Web. He uses the metaphor of the London Underground tube map to illustrate a web connected by RDF ontologies. Different lines represent different data properties of a relational database (e.g. calendar or event). Where those properties intersect (represented by an interchange on the tube map) with a subject (e.g. time or location), we find a value which is of real usefulness in our everyday lives. At the moment, those properties and subjects do not intersect to create values in terms of the aforementioned application and platform independence. Instead, we have to 'manually' connect them in our heads. In this regard, we are still pre-web (if we go by the measure of what the web set out to achieve).

You should be able to find his whole presentation here. You can also find a less cumbersome explaination some of what I'm rambling about at Paul's blog.

Posted by Ant at 11:48 PM | Comments (1) | TrackBack

September 17, 2003

Extreme Programming vs Interaction Design

Kent Beck is known as the father of "extreme programming," a process created to help developers design and build software that effectively meets user expectations. Alan Cooper is the prime proponent of interaction design, a process with similar goals but different methodology. We brought these two visionaries together to compare philosophies, looking for points of consensusand points of irreconcilable difference.

Beck v Cooper on

Beck says: To me, the shining city on the hill is to create a process that uses XP engineering and the story writing out of interaction design. This could create something that's really far more effective than either of those two things in isolation.

This end is going to be my primary objective for the coming 6 months. I'll be going with some others from The Corporation to the ForUSE conference, where we hope to hear more on how we get to this shining city. In true Rapid Application Developent style We'll probably end up do trial and error, hacking about with our process until it feels right. Will be reporting lots more on progress as it happens.

Posted by Ant at 11:29 AM | Comments (0) | TrackBack

More: Does UCD sabotage creativity?

A very eloquent comment on this from Gilbert Cockton...

One can design interaction however one wants. Tossing coins is an option, hence fate-centred design is a possibility. The question must' interaction design be user-centred must be false. How could it be true? What could force it to be user-centred?

There are many possible approaches to design . There are no inevitable consequences of (not) being user-centred. Good design happens without being user-centred, and bad design is not impossible when being user-centred.

It is not a question of being user-centred, usage-centred, designer-centred or art-centred. What matters is how we approach design and what guarantees come with different approaches. Very little can be said with any confidence at a level of abstraction that is as vague as 'centredness'.

HCI is about risk management. Being user-centred should reduce a range of known risks of systems failure or unacceptability, but only if the design team focuses on what is unacceptable and what will really make a system fail. In this sense, if we want a design focus at all, it should be success-centred!

Designing without any idea of what constitutes success is the real danger, and this is just as easy in a supposedly user-centred setting as in any other. Indeed, any approach to design that assumes that some element of quality in use must predominate is highly risky. Success depends on a wide range of outcomes, and usability and user acceptance are only part of this.

Our job in HCI is not to dominate the design process or to insist on a fixed set of approaches. Our job is to understand the human risks to success associated with usability and misfit with the context of use, and to work with project sponsors to get them to identify where success must include usability, user acceptance and system fit. The latter can only be achieved reliably and consistently within a user-centred approach.

So, in answer to the question "Does Interaction Design have to be user-centered?", the answer is "No, but if it's not, then be certain that this will not result in system-failure". This is the real challenge to advocates of non-user centred approaches. You get to be creative or whatever, but at what cost? What matters more, how designers feel or what they achieve?

Thankyou, Gilbert.

Posted by Ant at 11:18 AM | Comments (0) | TrackBack

September 16, 2003

RE: Does UCD sabotage creativity?

George Olson answers in an article on boxes and arrows.

Long and short of it... Getting insight from users and validating designs
against users doesn't mean one abdicates _designing._ There's a value in
user-focused design and a value in vision-based design, the question is when
each is more appropriate.
Thanks, George. :-)

Often we take direction for conceptual development from user research such as ethnography (and less so from focus groups or misguided user testing). It takes a great deal of effort not to get coralled into a certian way of attacking a problem when under the influence of a behavioural study.

I'm specifically interested in lateral thinking techniques which enable us to step outside what we think users can comprehend, with the view of stepping the resultant idea back toward something they will.

It's all too easy to become scientific about creating products as the discipline of interaction design matures. We not only seek more and more validation from scientific methods but also seek direction for conceptual development from them too.

In my opinion it's all about striking that balance between left and right hemispheres of the brain. What techniques can help maintain that balance?

Posted by Ant at 10:28 AM | Comments (0) | TrackBack

September 12, 2003

Knackered and Nathan

Just returned from a little consulting up in Wales... getting up at 6.15am and not getting home till 8.45pm is a bloody marathon.

They're a nice bunch up there and after a day of defining user personas for they're all g'd up to get on with a little user centred and goal-oriented work in re-defining their template system and branding. Yayy! One more for the good guys.

Reading the Polar Bear book on the train for 4 hours has been great. Really getting a nice handle on Information Architecture concepts I knew either in part or had misconceptions about. It's really readable for such dense content. A nice nugget within on Organising Information by

Posted by Ant at 09:34 PM | Comments (0)

September 11, 2003

Interaction Design vs Information Architecture

A group of collegues and I were arguing last night as to whether there should be such thing as the title 'Interaction Designer'. Mags said she reckoned that it was just a subset of what an Information Architect does. Alan Cooper certainly refers to an Interaction Designer in his book The Inmates are Running the Asylum but... was that written when web designers were just graphic designers from the print domain bullshitting that they could do interaction?

These days, I feel that to still be employed as a web designer, you must have got past just pushing pixels. Oh... I don't know anymore. What's in a name? All to bloody much!

Posted by Ant at 02:00 PM | Comments (0)