Archives:

User Centred Design


May 15, 2011

Moving the blog

The Vanity Experiment is moving to http://colfelt.com/index.php/thevanityexperiment

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://colfelt.com/index.php/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)

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)

February 04, 2010

Bringing User Centred Design to the Agile Environment

Latest article I've written for Boxes and Arrows is about "the minefield" of Agile environments for the UX soldier.

  • Mine 1: An unclear role for design
  • Mine 2: The requirements gathering process is not defined
  • Mine 3: Pressure to cut corners
  • Mine 4: The temptation to call it “good enough”
  • Mine 5: Insufficient risk-free conceptual exploration time
  • Mine 6: Brand Damage

Bringing User Centred Design to the Agile Environment

Posted by Ant at 08:57 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)

January 23, 2007

Take a look at what I've been building

Though this isn't new, its only now getting to the point that I care to share it with anyone. I am the Creative Director revamping the look and overhauling the infrastructure for myfamily.com. The old myfamily.com has a solid feature set, but is in desperate need of bringing into the new millenium.

There's still a long way to go before myfamily.com 2.0 beta has as rich a set of features, or the finesse in front-end code that I'd like to see, but it is out there. Soon we'll start advertising that it's there and we'll see what the punters think.

The above 'SnapGenie Story' is a part of the product that allows you to build narrated photo slide shows using a telephone and the pc. The voice-over is by yours truly.

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

August 01, 2006

Usability trends

My good man Alexander Muir forwarded me this rather good article which is a snapshot of the usability industry right now. As ever, the debate is about techniques which are progressive vs traditional.

Is usability testing as we know it about to radically change?

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

July 12, 2006

Clicktale - new usability observation tool

This tool makes little movies of a users' mouse movements and then analyses the results to tell you which areas of the page are most moused over, whether users are scrolling and by how much etc.

Slightly 'Big Brother is Watching You' but the assure us that there's nothing sinister going on.

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

June 29, 2004

Agile Mindset

Agile is a software development movement that aims to cut fat from the industry's trademark bulky timescales and bloated specifications. Its been devised by 'developers' or 'programmers' and as such has so far been pretty thin on procedural detail for the user experience designers. In fact, some of the specific methodologies within the Agile family make absolutely no mention of 'experience design' at all. Most advocate lines of code being written from the very beginning of a project. Almost all state that you work through a list of requirements until you have the minimum amount of functionality to release a product. However, few go into any detail about how you get to the point of having requirements in the first place.

So, this is where a project team used to working from the very start of a project (determining what it is that needs building) can go wrong. Trying to lay lines of code before you have some idea about why or for what purpose is like taking a journey to a foreign city you've never been to before, without looking at a map first. You may hit the right continent if you have some vague sense of direction, however, all roads do not lead to Rome.

But there's more to Agile than laying lines of code as soon as possible. Its a mindset which can rid the shackles of rigid 'design first' processes that pride themselves on quality but have done more than their fair share of creating the software industry's bad reputation by delivering late or not to specification or not within budget (or a combination of any and all of these). The Agile Manifesto is a set of fundamental tenets to remind Aglie practitioners to "Get On With It". And really, thats what it boils down to, regardless of which role you fulfill in the team.

In my recent experience of working on a project that was very much at 'seed' stage when we began trying to work out which of the many manifestations it could take on, I found that an Agile mindset was an effective mechanism for ensuring that rediculously tight deadlines would be met. Being Agile means that the perfectionist that lays within most experience designers has to be persuaded that it's OK to get it right the second or even third time. Taking a 'sketch approach' to design where the first versions are a best guess based on the knowledge available at that time, abates deliberation for fear of getting it wrong. Watefall processes are frought with fear of the bad specification. Once coded, a design is set in stone, not for revision. Technical folk usually get very cranky when you sheepishly sidle up to them with "You know that section here... the one that took you weeks to code, tweak and get just right... well... um... we er, need to um, change it... y'know, just a little bit..." [ducks for cover]. However, when the project team all agree up front that everything is subject to change, it loosens up that feeling of foreboding which has a side-effect of making people check thrice before committing to a specification. Naturally, changing things takes time, but when things take less time to design in the first place, you have more time to iterate until it is right.

A coding practice known as Refactoring can liberate us all from what Alan Cooper refers to as scar tissue, a phenomenon where code that has to be changed leaves a 'scar' that makes the foundations of the program unsound. It can be argued that working in an object oriented fashion should enable components of a system to be rebuilt with no impact on the remaining body of code, therefore should be the method of choice when following an Agile development process.

The Agile shift in thinking about experience design is not just about being iterative. Its fundamentally about designing in an object-oriented fashion too. Components need to be designed individually in order that they can be built individually in a staggered project timeline. Some components will be a few degrees more defined than others at any one time and this is hard to reconcile at first. Its uncomfortable thinking that you have to design a mid section before a start section etc. Some might say you can't possibly do it and expect to get it right. And there's the crux of the mindset right there. You don't expect to get it right the first time. You expect to get it right the second or third time around, when you have had time to design the start section.

Agile works, but the idea of laying lines of code from the outset of a project, does not seem like a great idea to me, for reasons stated earlier. I think this is where a production process can learn from User Centred Design's 'understand' or 'discovery' phase to flesh out business requirements, user requirements and the competitive marketplace. I would still advocate that the body of work that is done in this period, is managed using an Agile methodology like SCRUM though, as it still works to 'gee the team along' even when they're not laying lines of code. The rhythm set by being iterative, combined with an disparaging attitude to excessive documentation and ecouraging face to face dialogue, is a very effective framework to ensure maximum efficiency within the team.

It does take a significant 'opening of the mind' to allow ourselves to really work in this way, when everything we've known to date says we're going to get burned if we do. But it's inevitable that you get burned the first time you try new things. We must persevere, because unless the software and web industry embraces a total shift toward delivering on time, to spec and on budget, clients will continue to lose faith in its ability to get itself together. This will affect its monetary value in very real terms. If the tech sector's stock price collapses, as the survivors the dotcom crash know only too well, it will really, really hurt.

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

June 16, 2004

'Executive' User Centred Design resource

This UCD Executive Primer is a high level overview of some fundamental User Centred Design principles. It gives varying levels of detail on each (very) high level area of the approach and features articles on useful things like return on investment.

Seems like an ideal site for arming the user experience designer for selling this approach to tight-fisted and sceptical sponsors. It also just appears to outline answers to most of the arguments I've had over the past three years or so working within a large company.

If you can't get your point accross, point your boss to this!

Posted by Ant at 01:22 PM | Comments (2) | TrackBack

April 26, 2004

Questionnaires

Questionnaires in Usability Engineering

Over the years, I have seen many questions asked about the use of questionnaires in usability engineering. The list on this page is a compilation of the questions I have heard most often and the answers I gave, should have given, or would have given if I had thought of it first.

Compiled by: Jurek Kirakowski
Human Factors Research Group, Cork, Ireland.

Posted by Ant at 12:25 PM | Comments (1) | 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 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

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

February 28, 2004

Making New Products

I gave a presentation the other night at the Design Council in London that explained the User Centred Design process we went through when designing a product for 'The Coroporation'. Afterward, I recieved a good question in an email from one of the attendees. I'm publishing it here with my thoughts.

Q: "... in this case you already knew what you wanted to create, but 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?"

A: Market research is able to flesh out a lot more about where there may be gaps in the marketplace for a particular type of product. However, this can be quite trend based. After you have considered this you need to focus on ethnographic research and structure it in such a way that it exposes where people are getting around a problem(s) that illustrates to the aforementioned gap in the market.

Aside from these structured approaches, theres no substitute for a flash of inspiration. The research above is a good way to feed the mind in order to get to that point of a great idea. Present it to a multidisciplinary group of creative people and run a structured brainstorming session around it (that whittles down really good out there ideas into a few well defined concepts).

And occasionally, a flash of inspiration can come in the form on an idea from one mind and it spreads like a virus (memes). When they spread like that, its a pretty good sign theres something to it and user research then serves to validate rather than inspire.

Once youve arrived at an idea, try and boil down as many different permutations/manifestations of it as possible into sketch form and test for feasibility and user acceptance. Beware! Testing for user acceptance of an idea is a tricky business because the facilitation of any session will heavily influence the outcome. From this you will be left with a smaller number of options which you develop to the next stage and iterate this validation process until your left with one model you decide to develop.

An alternative to the creative people in a room method is to run a series of participatory design workshops with your target market, to work toward creating something that will be useful for them. This is not for the faint hearted, and is still a fledgling method. It can be very informative, it can also be pretty useless depending on how it is run. In my experience, its best to have small groups of lay people working with a user experience designer to help them realise ideas.

Posted by Ant at 02:03 PM | Comments (2) | TrackBack

January 16, 2004

Constructionism

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

November 28, 2003

SCRUM & UCD - Deborah Hartmann

This Diagram is one Deborah sent me illustrating how she's approached the effort to integrate User Centred Design with SCRUM.
TypicalReleaseA?|printRhythm.jpg
We're going to continue the conversation in the comments section underneath this entry. Feel free to join the discussion.

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

November 04, 2003

Syntagm Articles

Articles written by William Hudson who runs a UCD list over here in the UK are here and worth a read.

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

October 25, 2003

ForUSE - Conclusions

A few days have passed and I've had time to reflect on the conference now. There were a lot of different angles on design and process covered. Below is a breakdown of the takeaways that were the foremost impressions.

Process
Larry Constantine said it best in the final conversation that was held between the remaining delegates on the last day. "Process is like the training wheels for learning a craft. When one has gained enough experience one knows when to throw it away." Ron Jeffries also had a good way of describing process. "Process is like a Kata, you practice techniques over and over and over to make you learn the art..." Having once studied Karate, the notion of practicing set techniques in different combinations really resonated with me. Through practice, you can draw on your route knowledge of individual techniques and combinations of them, to best solve a problem when faced with it.

The conference presented numerous different processes and ways of 'skinning the cat', but ultimately each set of activities (process) should be tailored to the individual characteristics of the project at hand. You could set down some 'touch-stones' or general guides, but ultimately these have to be vague so as not to be too prescriptive. I've learned a lot more about new techniques and general rules of thumb, so this should be very helpful in laying these 'touch-stones' in the right place.

Usage vs User
"In usage-centered design the focus is on usage - on the work users are doing and the tasks they are trying to accomplish. Users, rather than being the center of attention, are involved in limited and highly focused ways to help designers build tools that will better support the work being done." More on this at foruse.com.

The emphasis of Usage Centred Design is much more on developing software and using notation and language that enables proper dialogue with technical teams. I know this is going to be more powerful than I can imagine right now. The divide between tech and design varies according to the personalities on both sides of the fence. However, through this framework I am confident that we can really begin to communicate properly and constructively. Most technical folk I have known have not been resistant to the tenets of User Centred Design. However seeing the relevance of some of the exercises and techniques has proven a sticking point in the past. I still believe there are appropriate times for applying some of the less quantifyable techniques for gaining context about user goals. However, we need not bog down folk to whom this has no bearing on the job at hand, just as they would not ask me to help write a few lines of code.

The nice thing about Usage Centred Design (U-CD) as a set of techniques and an overall process, is it seems a lot more focused on getting the job done. The areas of User Centred Design (UCD) that have caused me the most trouble with management (and sometimes the team), are those that produce no tangible deliverable for the end product except documentation. U-CD seems not to have the same kind of 'bloat' around it and I think that combined with the best principles of SCRUM wrapped around XP (as illustrated here), it is the kind of process outline that will work flexibly enough to accommodate all projects.

The exact nature of how the agile processes and U-CD mesh is yet to be defined. But the conference had some good examples and success stories, so It looks promising.

Return on Investment (ROI)
XP has the capacity to measure and predict ROI according to chunks of work called 'Stories'. Each story is attributed indexes of value, expense etc and can be prioritised over other stories (according to its overall value) to ensure the optimum return on investment. It is this kind of surety that enables confidentent strategic decisions to be made in the context of a programme of projects.

A Company needs to ascertain what it defines as 'Value' and 'Quality' in order to make decisions about their products' development, based apon these indicators. This body of work should be thorough and consultative with audience and staff. There is also a need for a clear understanding of the business' strategic direction to guide this work. Assessing comparative ROI on any new process means measuring the running costs and revenue of the current and comparing it to that of the new. An accurate assessment of the current running costs and revenue (before the change in methodology) is integral to measuring success.

Breadth and Depth
Breadth and Depth refers to the overall body of work to deliver a product. Depth is exivalent to detail - we delve deeper into the solution. Breadth is more about the big picture such as overall infrastructure and architecture. Agile processes advocate that in each iterative cycle you address both of these. This takes the form of a rule that each cycle must deliver someting tangible like code and also deliver the broader project work too.

Breadth and Depth for design means approaching things differently to what I or most designers I know are used to. However, theoretically it makes sense to design things starting with a sketch, and defining levels of detail iteratively in collaboration with the entire team.

Posted by Ant at 07:42 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

October 20, 2003

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.

DSCF0031.jpg
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

ForUSE - Keynote Speech - Bill Buxton

These are raw notes...

Initial distraction about two handed design, designs systems for use with both hands. Inventory of skills a particular audience has acquired. EG musicians, painters.

Everyone is bad at making "new products" in the software industry (not n+1 or new releases). To allay this, most companies will buy a new product and make it an n+1. Why are other sectors that maintain high standards of new product able to do this but the software industry can't? Other industries have a design phase in front of engineering for making NEW products. This sits really comfortably with me drawing a distinction between a NEW product and a n+1 product. N+1 products don't need as much design up front as totally new ones do to ensure it is as good as possible.

I wish people didn't ask questions that are designed to just needle a presenter. There's no point to the question and the answer doesn't help the understanding of the audience. Ken Schwaber said "no questions if they're longer than the answer". I like that rule.

Status quo is engineering to sales. We discussed last night that the design process needs to incorporate the time after launch and factor in post release maintenance, support and version updates.

Film industry example the PACKAGE before work begins, or "green light" - Stars signed up. Nailed down with contracts FIRST. Script. Production Schedule. Release date and season. Title and campaign. How much will be spent on marketing. Location, Director of photography with photos of the location... etc. Then the decision is made. Lesson in Venture capital pitches - thorough scoping.

Automotive Design example sketches, clay models, work closely with engineering. Based on a platform (chassis). Engines and Platforms are hugely expensive and are thus reused. The shell and styling are what make the car. End of the design phase has a concept car, that looks like you could drive away in it, but it's all clay! That happens before the 'green light' is given. Feedback from the audience. 'focus groups' are shown the concept car at shows etc to gauge potential success.

Design phase comes before 'green lighting' a project. This includes all projections of marketing potential, cost and acceptance. We need to have a marketing department who understands what we need from them.

Innovation can still come in the engineering phase, but through implementation, not design changes. It is also essential that there are engineers in the initial design team. A lot of car companies are trying to reduce the design phase through a lot more ethnographic research and contextual enquiry.

Essentially, Bill Buxton agrees with Alan Cooper in saying there's no way to design and engineer at the same time and end up with a well designed and successful product.

Criteria Weight increases as a function of time and investment. Criteria meaning the specifications for success. You need to have a 'dashboard' to continue to monitor whether the product is meeting the criteria you initially set. Think Ken Schwabers' geese finding solutions to a set of requirements when migrating. e.g. of Criterion "80% of the functionality to be understood and learned within 5 minutes" "must be able to be used on all platforms" etc.

Personality types: Designers - change in half an hour, innovate and come up with new features all the time. Engineers - totally organised and anal, not likely to try and introduce things at the end of a build...

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

Portsmouth, ForUSE, Jeff Patton

Arrived in Boston last night at about 9.30 and made our way somewhat tortuously to the Hotel in Portsmouth from Boston Airport via running for a coach and then catching a cab from the 'Stoppango' to the Hotel where the conference is to be held. Why are hotels all so much the same? This one feels just slightly tired and in need of a facelift. But basically very comfortable... mustn't grumble and all that.

Woke up this morning at 'Sparrow's Fart' which was about 5 am... then again at six because the assholes in the room before me left the alarm set for that time, then again all morning till I got up. Spent the day exploring portsmouth (see gallery below).


Portsmouth Pictures

The first of the reception gatherings was held in the evening where I met a few people. One of which was Helmut Windl who works for Siemens and is an associate of Constantine & Lockwood who put this conference on. He's been working toward integrating Performance Centred Design and Usage Centred Design. Some of what he's worked toward is a making workflow obvious to the end user through the interface (basic example would be representing the steps in a linear process). He's extended this to forming a hybrid between an object oriented use case and a user task flow to aid in the development process. He also talked about prioritising features against criterias of frequency of use, overall importance (to tasks), and business importance. I was still jet-lagged a bit, so I couldn't really get the most out of what we were discussing. He had more to say. It didn't stick in my head so well.

Helmut did however, pull Jeff Patton over to talk to Lorna Ledden, Andy Scotland and I about what we're here to glean - how to integrate User/Usage Centred Design with agile processes such as XP and Scrum. Jeff has had a lot of experience with this very thing. The first thing he talked about was measuring risk on a project to determine how much design needs to be done before coding should begin. Risk assessment is done through measuring potential revenue loss versus amount of resources that will be building a given product (i.e. potential money lost on final product vs money spent to build it). Risk becomes a function of design lead time.

We also talked about our past experiences with different processes from UCD to XP to SCRUM which was useful in that he had some insights for us about involving all team members but at the right level and time. I think that this confirmed what we knew from experience but still don't have a handle on the fix yet. How do we get that balance right? Jeff suggested he knew of some techniques to get it right, but wasn't able to demonstrate at the time. Might have some supporting info later.

Posted by Ant at 04:35 AM | Comments (1) | TrackBack

October 15, 2003

Why users shouldn't be at the Centre of Design...

When others dont buy into doing things the right way, they are often dismissed as unenlightened luddites who dont understand the importance of what we do. Thus, some practitioners develop a UCD inferiority complexa resentful feeling that were not appreciated or understood. Often this results in the practitioners return to more comfortable territoryconversations within the UX community about methods or tools, or how engineers or marketing just dont get it. And that leads us to what might be the biggest drawback of UCD.

From Article entitled Searching for the center of design
featured on Boxes and Arrows

Probably the best summation of my experience with UCD evangelism to date (including, dare I say it, my own).

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

October 13, 2003

SCRUM

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'.

resource_distribution.jpg

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.

UCD_SCRUM_integrated.jpg

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

September 26, 2003

Links a plenty

DigID

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.

"Create-ivity"

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

Random

Grays Anatomy Online. I always loved the book, now it's online.
Posted by Ant at 11:40 AM | Comments (0) | 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 Fawcette.com

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

Does User Centric Design sabotage creativity?

I know a fairly well respected person in the industry, who has started championing 'Designer Centred Design' which has the hackles on the back of my neck standing up.

This person's rationale is that as designers of interaction (or insert related job title), its our job to know what users can and can't do, not to ask them what they can and can't do (through testing or other means). This may appeal to the inner self-indulgent and lazy designer that I beat into remission some 4 years ago. But it does raise a few interesting points for the designer I am today.

Here's one...

If we're always asking for validation from our user base on everything we do from project start to project finish, where does innovation come into the frame? Surely if we are always making design choices based on what users can and cannot do, how do we introduce new (and preferrably learnable) mental models into our user's psychy? Does making something usable and understandable first and foremost, trounce any inspiration that may yield 'weird' or shall we say 'innovative' ways of defining a system model?

Posted by Ant at 12:11 AM | Comments (1) | TrackBack