The Seven Circles of UX Heaven

Another of our iterations of the UX Ecosystem model.

The Seven Circles UX Ecosystem Model (click to enlarge)

 

So far, I think I like this one the best.

M

More on the UX Ecosystem: No, you still can’t design a User-Experience

Can you design user-experience?

I’ve continuned to ponder on the issue of experience design and the catch-all label of UX since my last post. The more I think on this the more I feel strongly that you can’t design what people popularly call ‘user-experience’. You can, though, account for the variables that contribute to an experience with some of these being easier to account for than others. In essence, this is because we can influence how someone is likely to feel when they experience our products and services but we can never hope to account for the myriad of possible contexts and motivations a person might have.

I’ve now added the business-focussed elements that contribute to the perception of value in the experience and have articulated with greater emphasis the role of the domain of psychology in the mix.

M

Beyond UX: Design or Development. Destiny or Death.

What is user experience (UX)?

For some, ‘experience’ has been synonymous with two decades of visual design powered by Photoshop — a lifetime creating beautiful, engaging, online products that started with the humble joys of picking up our first mouse. For the lucky ones, it’s been a journey of keeping up with an ever changing technology landscape and the opportunity to bring new platforms to new consumers with new devices from smart phones to Tablets. But is this what creating awesome user experiences truly about? Is it as simple as beautiful design or smart development, or is it something deeper?

As we explore a 21st century driven by UX, we’re reminded what design is supposed to mean by the words of the late Steve Jobs:

“In most people’s vocabularies, design means veneer. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product”

So how do we achieve this goal? How do we give our products a soul that yearns to be experienced? This presentation given at Creative Camp NZ in 2011 will give you a glimpse as to how you can capitalise on the growing demand for truly awesome UX.

M

The UX Ecosystem

Can you design UX? I feel there’s a growing movement that says ‘no’, but that:

1. You can design for a specific user-experience
2. Users are likely to use your product and/or service in ways you never thought of and so will have a user-experience that was completely unaccounted for and definitely not designed.

Do what can you design? Peter Morville’s Honeycomb Model of User-Experience gives us a glimpse, but I wanted to go further and examine the whole ecosystem of experience, from desire and action to reinforcement, and see what part we as UX designers can architect. I feel strongly that the solution is in understanding the psychology of decision-making that leads to an action. If the perception and evaluation of the outcome of the action is favourable, then it’s more likely to occur in the future. Mix this outcome with the hyperconnectedness of people in the 21st century and you have a feedback loop for experience — in essence, an ecosystem.

This is a slight adjustment from the image in my last post — the addition is the feedback loop with word of mouth acting as a filter to the relevance of usefulness, desirability, credibility, etc.

The implications of this ecosystem are actually quite significant for those who label themselves UX Designers:

1. You can attempt to design something that is accessible, findable, useful and usable. These are pragmatic elements.
2. If you have sufficient knowledge of human psychology, you can create factors that will have a certain level of influence over the subjective perception of whether a product is useful, desirable, credible and usable
3. Collectively, these factors equate to only one perception of the value of the product you’ve designed. Because you can never predict human behaviour 100% of the time, the factors you’ve spent time designing will only ever account for a small proportion of the perceived value and resultant behaviour towards its use
4. Just because someone desires a product that you’ve designed it does not follow that they will have sufficient knowledge to know how to use it
5. Just because someone has enough knowledge about credibility, desirability, filtered from their networks, it does not follow that they will decide to use it (action)
6. You can only design for awareness and desire. Knowledge, action and reinforcement about personal experience of your product in its environment of use

This means its a good day to have psych + UX skills.

M

User-Experience Can’t Be Designed

I’ve been reading a thought provoking article by Helge Fredheim over at Smashing Magazine on “Why User Experience Can’t Be Designed“. It provides an interesting summary on Hassenzahl’s model of UX noting that UX can only be designed for, particularly given that designers can only focus on requirements for “task solution, final goals and achievements” and that UX goes beyond these to include and encompass “other aspects into consideration as well, such as emotional, hedonic, aesthetic, affective and experiential variables”. These, of course, are all psychological factors — something close to my own heart and that I am all too aware of that few people who call themselves User Experience Designers really have any great knowledge of, let alone any strong capability to turn these into requirements in order for developers to build.

I thought I would add fuel to this fire and add in a model based on the transtheoretical model of behavioural change that reinforces the psychological complexity of what we’re now calling UX. It goes beyond Peter Morville’s Honeycomb model for UX and places it firmly in the context of use, action and reinforcement of that action to either negatively or positively impact on the likelihood of futue actions.

UX in the context of use as articulated by the transtheoretical model of behavioural change

This perspective reinforces that a user’s experience isn’t just about content, or visual design, or a subjective experience based on usefulness or desire, but a reinforcing loop that goes beyond just creating a desire to use a product or service and whose outcome predicts whether someone is likely to re-engage with your design again, or whether they will tell everyone in their social circles powered by Twitter, Google+ and Facebook, that it’s crap and not to bother. It means, moreover, that unless you have a multi-disciplinary perspective in your Teams’ skill set (likely powered by Agile methods) you’re going to be unlikely to adequately produce the base requirements expected by modern users of their experience.

M

UX + Agile: You’ve forgotten the ‘inspect adapt’ process!

The biggest advantage in using Agile methods is the ability to use inspect/adapt processes. Put simply, this means at the end of each Sprint the Team works out what worked, what didn’t, how the environment has changed the priorities of work ahead, and gives the Team a chance to adapt subsequent work to those issues.

Agile at its simplest -- Plan, Do, Check, Act

 

The bulk of UX + Agile whitepapers and blogs in the last few years recommend doing parallel work with one sprint in advance so that there’s enough vision and clarity ahead of the build phase to create highly usable products.

 

A version of the parallel design + dev tracks made famous by Lynn Miller (2005) and then Nielsen & Nodder (2009) as a preferred way ot undertaking UX + Agile projects

This approach is not very smart

This parallel track of work seems, in principle, a faily sensible way of working, and it is. But it isn’t Agile. It’s just another way to describe the deterministic approach to software development that is typical of Waterfall projects. The flaw that Lynn and others make in this way of working is that the UX Sprint becomes quickly out of sync with the Development Sprint.

Parallel design + dev tracks quickly create divergent priorities

... or worse ...

Should the retrospective at the end of Development Sprint identify new requirements, changes to the environment, the initial plan was wrong and must be re-thought, or any number of things that result in the products to be develop suddenly needing to be changed, the UX Sprint has wasted their last 2 weeks of work. If this way of work is to continue, it will require the UX Sprint to become ahead of the Development Sprint. In this event, there arn’t many choices. You simply have to stop development until you can design for the change in requirements.

Overall, these sorts of approaches only show their ignorance of Agile methods and what they are designed to offer Teams and their clients. The only concern that drives these approaches is not how to become Agile, but the worry that without design expertise such as UX, IA or UCD applied to designs up-front, the Team will somehow fail.

 

So what do you do?

Integrating both parts of design and development is a good start to making a Sprint work effectively. This enables both the developers and the designers to undertake the retrospective together, learn from their mistakes, and re-prioritise the work for the next sprint accordingly. This approach is sort of a mini-waterfall inside an Agile wrapper. Most often, I’ve heard this referred to as Spiral, and it still isn’t Agile. This is because while this is an iterative approach, it still has design before development in a serial process, which is the core of Waterfall.

Design and development in the same sprint, but in serial

Design methods like user-centred design and user-experience design are only traditionally done up-front because there has been little chance to make changes after development has started. This propensity continues to filter into interpretations of Agile with the assumption that this statement still holds true. Something that designers of all flavours need to understand is that with Agile this belief no longer holds true.

 

A new hope?

Scrum is one of the most popular Agile methods. In it there are only three roles:

1. The Product Owner — typically the client who chooses what the Team will do in each Sprint
2. The Scrum Master — the one who helps remove barriers to work getting done so that the Team can focus on the job ahead
3. The Team — a multi-disciplinary approach to produce a product (working code, service, a book … what ever)

Key to the Agile project's success is the ability to look back on the last Sprint, learn from it, and empower the Product Owner to change his mind about what needs to be developed due to changes in the project's environment. This is core to Agile.

Designers are typically unaware that Scrum Teams spend 10% on planning up-front. If the Sprint is a whole week (1o days) it means the first day is spent planning how to work together, what needs doing, and how to produce the whole product according to the Product Owner’s criteria (known as the ‘Done’ criteria). There’s plenty of time for designers to integrate UX needs into the Sprint ahead during planning through using User Stories, data-driven Personas, and Storyboards as planning tools to help the team decide how big and/or complex certain features are likely to be and therefore how they can work together to complete the associated products.

The typical flow of actions during Sprint Planning when UX tools are employed

Working with the Product Owner & the Done criteria

A designer must work with the Product Owner to raise awareness of the value of having good design principles in the products the Team produces. Typically, this manifests itself by including UCD principles into the Done Criteria (which is defined in Sprint Planning). This means that for the product to be signed-off and approved at the end of a Sprint it must pass the UCD principles that the Product Owner put into the Done Criteria. Importantly, in most Agile contracts I’ve seen, if the product doesn’t pass the Done criteria then the Team doesn’t get paid.

 

Working with developers in the Team during Sprint Planning

When a Product Owner decides (or changes his mind from last time) about the items he wants produced, the Team first gets together and works out the most effective means of delivery, makes plans, and then creates tasks. They spend a whole day doing this, which is plenty of time to do some quick user research by examining recent projects, create data-driven Personas, make storyboards, and assess what systems functionality required will by the people, in their context of use. This is a planning process that I use and find it to create a higher definition of tasks and better estimates than playing Planning Poker alone.

 

Sprint Planning has always been about establishing a common understanding of the needs and issues of the products to be built, their requirements, and how to achieve them. In essence, creating a common vision of how to proceed. In this, design tools become a critical strategic planning tool.

UX + Agile as Scrum

Rather than creating new processes in an attempt to integrate UX design processes into developers’ Agile methods, try and adopt Scrum. In doing so, make sure you get a good coach to help you implement it as best as you can.

 

Where can I learn how do I adopt these practices?

If you’re interested in these techniques, Zen Ex Machina is running workshops at Creative Camp NZ this October 2011.

M

Scrum Infographic

What goes on during a Sprint in Scrum? What tasks and activities could be done, particularly if you’re embedding UX methods and deliverables into the Sprint?

I’d be very interested toread what you do in each of your parts of your Sprint

M

PDCA and Scrum — A view that makes sense

Just toying with a diagram for a friend to represent PDCA (a Deming Cycle) as a Scrum’s sprint cycle.

PDCA (a Deming Cycle) as Scrum. Click to see a larger image on Flickr.

And then there’s also this version, which I think is my favourite.

An alternate icon view of Scrum as PDCA

M

Costing Agile Projects

I’ve been looking at a number of issues around costing and contracts for Agile projects. The perspectives of different parties and their expectations couldn’t be more different.

1. What the Clients wants

The client wants, and rightly so:

• Scope – Delivery of all the functionality in her list (no less … but maybe more if her needs change)
• Cost – Fixed costs, so she doesn’t go over budget
• Schedule – An assurance that the project will be completed to her timeframes

Unfortunately, because contracts are typically negotiated by accountants and not anyone from the Team who will complete the project, no one can raise awareness that this approach all too often adversely affects the quality of the products the project produces.

2. What the Team wants

What the Team wants, though, tends to be:

• Scope – A fixed set of things to do
• Cost – Payment based on the actual time and effort spent on the project
• Schedule – Flexibility in the timeframes so that it takes as long as it takes to create the functionality in the Client’s list

Overall, the Team doesn’t typically want anything to affect the quality of their product because this means a loss of their reputation. In other words, if they make a poor product no one will want to employ them. I know I wouldn’t engage a Team who produces poor products.

Unfortunately, the want to keep product quality high is left out of the contract negotiations.

3. The typical response – Time & materials contracts

I’ve seen first hand from a number of organisations I’ve worked with, on both the Client and Team side, the compromise resulting in a time and materials contact.

• Scope – Locked down with a change control process added to lessen the impact of change
• Cost – Payment for effort over a certain time, but not based on what is actually produced 
• Schedule – Explicitly tied to cost, that is, as long as it takes to complete a fixed list of products.

What is now left out of the contract entirely is the quality criteria with cost metaphorically handcuffed to fixed timeframes (e.g. manifested as weekly timesheets).
>4. An alternative contract frameworkI’m going to come right out and say it – I do fixed-price contracts  with a fixed-scope of work in a fixed-timeframe for my Team’s Agile projects, but with the following provisors:

• Scope – The scope that can be delivered in a fixed timeframe is assessed and rated according to its size (XS, S, M, L, XL, etc). A project I’m currently working on has a fixed size of scope of 33 units. Each size has an associated unit of measurement and based on previous velocities of the Team, they can accomodate about 35 units of work per Sprint with reasonably clearly defined Done Criteria. This is the rate at which we have agreed is sustainable (very important) and a rate to which the Team has agreed to our Client that they will work to. We have penalties for not working to this agreed rate, but we also have bonuses for working ‘smarter’ and delivering more than what was agreed to, or delivering to a higher-level of value, so long as the output is produced in accordance with the Client’s Done criteria.
• Cost – The cost is fixed to the delivery of products in the Scope. In my experience, this results in the Client thinking more about what she needs produced in the here and now, rather than wanting to see timesheets. It also helps to remind my Team of Jedis that, as their Jedi Master, I’m after product based on the clients needs and not an 80hr week. If I’m hearing feats of heroics out of their Standups then its time to step in and interveine and work out why:
• What caused this unexpected effort (usually something unexpected popping up)
• Why were the original estimates incorrect (very likely)
• Were we working on new functionality that should have been put into the Backlog (highly likely)
• Schedule – The product delivery cycles are fixed (ie: timeboxed) to two weeks, or how ever long the Sprint needs to be to deliver a working product.

Of course, this leaves ‘quality’. I’d like to suggest that it’s up to the client who is paying for the work to determine what his quality criteria are. That is, the client produces a definition as to what he’ll pay for at the end of the Sprint. In order words, the Client creates the Done or Sign-off criteria for his products at the beginning to set expectations as to what he’ll pay for at the end when the product is produced. This criteria can change over time, as it gets more explicit and harder to meet, the cost for that product is reviewed.

5. What is needed from a Done Criteria Contract?

In the same way traditional contracts highlight a process for negotiating changes to scope, the Done Criteria Contract formalises refinements to what the Client expects from her working product — the value and quality she wants in the product she’s paying for.

In essence, this sets the expectations amongst the Team as to what tasks they need to be undertaking to complete the scope, and requires the Client to be highly specific and up-front about the quality she’ll sign-off on and then (importantly) pay for.

As the Done Criteria is refined, becomes more complex, or more difficult to achieve, the Team can adjust its estimates of how much product can be completed within the fixed timeframe. Importantly, with greater specificity around the Done Criteria comes an associated increase in costs. The increase in costs is a discussion I have with the Client, not one that I involve the Team in.

Obviously, changes to the Done Criteria are timeboxed so as to not impact the cadence of delivery of the scope.

6. What goes into the Done Criteria?

It might be overly simplistic, but the Non-Functional Requirements (sometimes referred to as the Business Constraints) form the basis of most of my Client’s Done Criteria.

7. What about Agile’s famous flexible Scope?

The Done Criteria Contract doesn’t fix scope in the traditional sense, it only requires:

• Immediate Scope of products to be defined sufficiently for the Team to size it in a Sprint Planning session collaboratively with the Client as a formal Gateway to the commencement of work. If the Client isn’t available to collaborate on this effort, work does not commence.
• A formalised Product Backlog Grooming Workshop once per Sprint in which the Team and the Client can get together, review what’s coming up, discern the size and complexity of items in the backlog, the sorts of tasks involved, and gain consensus on its Done criteria. I timebox this activity to 2.5 hours — one morning that ends in lunch on the first day of the second half of the Sprint.

7. Using rapid consensus over lengthy processes

Contract changes are notoriously lengthy, with change processes driven through committees and sign-off processes. Some believe it important, but in my experience so long as the contract empowers the governance framework and its roles then contract changes can be (and are) relatively straight forward.

• The Done Criteria for Sprint One is an Annex to the Contract
• The Client can change the Done Criteria during Sprint Planning through collaboration with the Team
• The Team can resize the elements of the backlog when the Done Criteria changes
• Consensus much be reached at the end of Sprint Planning on the size of items with an agreed understanding of the Done Criteria
• The Team communicates to the Client how much can be accomodated in the Sprint
• Changes to the Done Criteria are confirmed by Email from the Client

Conclusions

This is certainly a different perspective on contractual negotiations, but I find its an important and powerful one because clarity of value is at its core.

I’d definitely be interested to hear your thoughts on this way of working.

M

From User Stories to Storyboards to Tasks

For me, Sprint Planning is usually a day of doodling on white boards, sketching on paper, arguing and sticking post-it notes all around the room. The idea behind all this creative energy is simple:

1. The Product Owner is trying to revise the order of the items in the Product Backlog
2. The Team is helping the Product Owner by make suggestions about the order, based on their respective areas of experience. For example, the UX-guy might note that for end-users, certain products would go a long way to making the experience better. The developer-chick might note that a few bugs should be addressed sooner rather than later and that certain architecture needs to be built first before some of the other items can see the light of day
3. The Team then attempts to break up the items the Product Owner wants into User Stories, ie:

“As a [user role] I want to [do something] in order to
[have an outcome|get some value]“

From this point, most of the Teams I’ve coached want to break down the User Stories into tasks to get the job done. This is what I suggest to them instead in their Sprint Planning sessions.

1. Create Personas for User Stories

It’s not difficult to ask the Product Owner the types of people he thinks of off the top of his head that are typical of the types of users the functionality is aimed to serve.

• Create a list from the User Stories on post-it notes
• Work out their typical age category – Senior, Baby Boomer, Gen-X, Gen-Y and Gen-Z. Forrester data is easily discoverable by doing a google search. It’s categorised by generation and shows the likelihood of certain types of behaviour. Research by the BBC supports the hypothesis that the biggest factor in predicting online behaviour is people’s age.
• Note their geographical region – Metro, Rural or Regional. Data from the Australian Bureau of Statistics (ABS) notes that people’s use of digital channels is determined by their regionality. You might expect that city dwellers have the highest download usage, however remote Australians are one of the biggest use of 3G mobile broadband in the country. This is really only because ADSL/ADSL2+broadband isn’t available, cable is as rare as hen’s teeth, and satellite connections are patchy. Their best means of connecting — their 3G iPhone!

Personas start with something as simple as a list of post-it notes on the wall

Armed only with this data, you can get a real sense of where a Persona lives, their age, and what sorts of behaviour are they most likely to engage in — post photos on Flickr, create blog posts, join forums, or just spectate.

One more thing I like to add is the Persona’s motivations from a psychological perspective. That is, why do they do the things they do and what do they value. I just make it as simple as a reference to one or more things that Maslow’s Hierarchy of Needs, or French & Raven’s Power Theory, describes in relation to the Persona’s behaviour.

Adding a Persona's reasons for action -- their motivators -- helps to reinforce that what they're doing is an attempt to get a specific outcome as articulated in the User Story

2. Create a storyboard for the User Story

Taking onboard ISO: 13407‘s simple principles of creating an understanding of the context before you look at the requirements, I coach the Team to create a visual storyboard. This is as simple as getting a piece of butcher’s paper or even just a swag of post-it notes and setting out a logical sequence of events that depict the user (I try to reinforce that we use Personas) in the User Story.

Persona 'Claire' in the context of her use of a system

3. The functionality in its context of use

Obviously, the storyboard depicts certain system functions or products. The next step is to articulate what that functionality actually is likely to be.

Personas in the context of their environment, with benefits, outcomes, pain-points mitigated and functionality all listed against that context.

4. Describe the value of the functionality

What happens if you deliver the functionality in the context described? Does it mitigate a pain-point or a risk? Does it deliver some sort of ROI, outcome or benefit that the Product Owner described when he ordered the items in the Product Backlog?

Describing the value is important for traceability as well as for the user-experience. In creating this view of the Persona’s world, it establishes the rationale as a Team as to why ‘Gary’ (a Persona) needs his experience to unfold in a certain way.

5. Now its task time!

The ‘Epic’ on the window (yes, that’s what some people call it) is now the collective understanding of the finer detail in a User Story. Armed with this understanding amongst the Team as to what Gary wants, the Team can now have a much more informed way of deciding what tasks the Team need to do to make Gary’s experience a reality.

This is how I introduce UX to my Agile Team. It means, overall, that UX is integrated from the planning of each Sprint and right into the types of functionality that the developers will create. If you’d like to learn more about this way of working, Zen Ex Machina is running a workshop at Creative Camp in New Zealand. I hope to see you there!

M