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. Sally’s 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 can’t be seen to be playing with her phone. One hands-free glance is enough for her to see what Jen’s 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 didn’t 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 it’s 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 it’s 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 it’s good or bad.
  • Make the story succinct and engaging. You need to hold the reader/viewer’s 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 isn’t perfect.

Common pitfalls


  • Don’t 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 18, 2004

Supplies

Please don your hat that doesn't object to politically incorrect jokes... it is a joke after all.

An Englishman, an American and a Chinaman are in a battle situation and are being appointed the CO's of different units by the commander in chief. The chief says to the Englishman, "OK, you Brits are good at talking, so you be the diplomat and see if you can talk our way out of this..." and then he turns to the American and says "If he fails, you yank's are pretty quick on the trigger, so you head up the armed forces and blast em to hell..." and then he looks to the china man and says "Hmmm... OK I'm not sure what the Chinese do well but we need someone to keep the supplies, so you supply the ammo and stuff for whole outfit". Anyways, the battle heats up, the Englishman goes to the front line to try and negotiate and is promptly shot. So the American sends his troops in to kick some ass, but gets about through a half day when they start to run out of ammo and says "where's that darn Chinaman? He's supposed to be supplying us with bullets". He finally gets desperate when he's suffering heavy casualties and the enemy is on top of them, so goes to look for the Chinaman. He hunts high and low and can't find him anywhere. Finally he goes to the 'munitions dump to fetch the ammo himself and just as he's loading up bullets, out from behind the boxes jumps the Chinaman shouting "supplies!!"...

Sometimes you stumble accross someone's web log and you know they know people you know and you just can't work out who it is... and then you pick up on nuances of speech/type that 'sound' familiar and guess their identity.

Tonight I discovered a good mate of mine started 'blogging at the start of the year and never told me. Perhaps just because he's not into all this "ooh, I read so and so's blog who was quoting so and so's blog" stuff... I mean it does get a little incestuous and vain (hence the name of this one). But in a way that's the whole point, it's about inspiring each other, supplying one another with food for thought and suppliesing them with little gems like this.

Welcome McWebb to the world of the 'blog. You are now officially a wanker, just like the rest of us. ;)

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

March 16, 2004

Persona Misnomer

Microsoft have been using user archetypes for a while now and have released some interesting papers on how they can be deployed in development teams, but I have reservations about the recent publication of MSN's personas.

The purpose of defining an archetypal user from data about many users who form your current and target audiences, is to give a 'Persona' to statistics. The very act of boiling down figures into a tangible, realistic character helps focus a team on who they are designing and building for. But for this to be a worthwhile, non-refutable exercise, the personas must be realistic. Being realistic means being non-elastic, team members cannot stretch 'Mandy' into any variety of people to validate the design they personally advocate. If 'Mandy' doesn't understand how to enter a URL into an address bar, that does not mean she doesn't understand most of the week, but does on Sundays.

So, stating that Amanda is age 14-17 makes her unrealistic. Exactly how old is she? Unreal personas will quickly lose any value they may have had because as soon as you apply them, any decision can be refuted with another angle from within the definition. If the definition is specific and acute, there are few degrees of difference in what 'Amanda' will fundamentally understand and like.

MSNs personas are unreal in other ways too. All are particularly aspirational characters. Where's the realism? None of these people have even a sight impairment, a common characteristic that would have a significant impact on design.

Finally, the cue for the argument against what I'm on about here. If we're being truly user centred, we have to acknowledge who these persona web pages are aimed at. I would guess they're not even used by the internal design team, but have been conjured by the marketing department to depict the perfect audience for investors in advertising on MSN. Notice how they all use MSN products all day long? Notice how 'Jessica' manages her finances with MSN Money after a busy schedule of using MSN for her entertainment, socialising and news? I mean, c'mon lets get real! With all of Microsoft's recent disclosures of security gaps, who's going to trust them with the most private of affairs in one's life – money? Obviously some people do, so perhaps I'm speaking through my hat.

The point is, these personas aren't realistic. They appear to use nothing but MSN which is of course what MSN would have any potential advertiser believe. But are they personas? Is there a more appropriate name? Is it pedantic to want a distinction between these dream users and realistic personas used as a design tool? Did the design community steal these from the marketeers in the first place and therefore let them have the name personas and come up with a new one?

Posted by Ant at 12:16 PM | Comments (2) | TrackBack

Let there be light

Concrete casts new light in dull rooms

The days of dull, grey concrete could be about to end. A Hungarian architect has combined the world’s most popular building material with optical fiber from Schott to create a new type of concrete that transmits light.

This is a beautiful invention. I wonder if you'll be able to tailor it to your designs, like having more optic fibre in some places over others? The variation in density of light you could create a whole new architectural art form.

Thanks to Sri for "brightening" my day with this article... arf!

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

March 08, 2004

Making New Products : More

This is an extension of this post...

Claudio Toyama, who originally kicked this conversation off with the question: "...what would the steps be if you were going to be very innovative trying to create a new service that has never been implemented before?", had the following additions to the discussion.

I also find that semiotic and ethnometodology analyses can be a very good tools for analysing cultural trends and it also help you understand what the customer might be seeing/perceiving, which can be completely different from what you are trying to convey - hence the communication gap...

Another research method that I find interesting in understanding customers' minds is the imprint and zmet analyses as both deal with the unconscious and emotional desires of customers and not the rationalised values commonly accepted by society.

One case study that your comment reminded me of was the New Coke. Market research found that the New Coke was going to be a great success but they were not counting on the fact that people like to 'stick to' the same things based on their emotional value and people are very adverse to change...New Coke being offered alongside the 'Classic' one is great but please don't try and substitute it.

Although I can see the value for products that are currently lacking in the marketplace, the only criticism that I may have for participatory design workshops is that a lot of the time a customer has no idea of what is possible and what's not. I'm not sure about the outcomes of this methodology if it was applied to a completely innovative and futuristic idea.

My worry would be that the lack of understanding from the consumer at that moment in time would hinder the development of a product for the future.

Thanks Claudio!

Posted by Ant at 10:21 AM | 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. It’s nothing but a pain in the backside they’d 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 don’t trust this interweb thingy with their personal data. They’re sure big brother can infiltrate it and come kidnap their kids. So, be transparent about how you’re going to use the data and ensure that the system is secure and solid in behaviour (if it behaves "all flakey", you’re 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 what’s involved at a glance and it doesn’t feel like you’re 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... It’s 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 what’s coming up. This isn’t always possible, but it’s an ideal to strive for.
  9. Provide lots of contextual help in the interface (any ambiguous terms should be accompanied by a ‘What’s this?’ link)
  10. Be consistent in layout. People don’t want to miss anything. If you have every widget in a consistent place, they’re 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 you’ve 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 don’t 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 shouldn’t 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 they’ve endured this painful process.
    Posted by Ant at 10:07 AM | Comments (1) | TrackBack