Another of our iterations of the UX Ecosystem model.
So far, I think I like this one the best.
M
Another of our iterations of the UX Ecosystem model.
So far, I think I like this one the best.
M
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
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
Can you design UX? I feel there’s a growing movement that says ‘no’, but that:
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:
This means its a good day to have psych + UX skills.
M
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.
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
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 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.
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.
Scrum is one of the most popular Agile methods. In it there are only three roles:

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
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.
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.
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.
If you’re interested in these techniques, Zen Ex Machina is running workshops at Creative Camp NZ this October 2011.
M
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
Just toying with a diagram for a friend to represent PDCA (a Deming Cycle) as a Scrum’s sprint cycle.
And then there’s also this version, which I think is my favourite.
M
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.
The client wants, and rightly so:
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.
What the Team wants, though, tends to be:
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.
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.
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 framework
I’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:
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.
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.
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.
The Done Criteria Contract doesn’t fix scope in the traditional sense, it only requires:
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.
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