Wednesday, February 15, 2012, 6:30 PM

Caplin will be hosting an “Agile UX Safari” in a couple of weeks. It will be a little different to the last one at MindCandy (we don’t have a tree house in our boardroom!) but we share their passion for design and development and mixing the perfect Agile/UX cocktail.

Check out the event –  We look forward to hosting a healthy discussion on all things design, UX and agile.

Hello again and welcome back to the Psychology of UX series! Today’s topic is all about MISTAKES. But before we begin let’s just define…

What exactly is a mistake?

“..a decision or action, or lack thereof, that we fear we’ll come to regret. They usually cause some degree of pain, loss or struggle,” says Mel Schwartz from Psychology of Today. For a more software-based explanation we might say a mistake is simply something that is wrong or that causes a problem with a user’s normal workflow.

Yes, mistakes. We all make them. We wish we hadn’t. One snooze button too many. Spending money on things we shouldn’t. Having that extra cocktail at work drinks and breaking out your embarrassing dance moves….I’m divulging too much of my personal life. But what about mistakes in the digital world? What happens when a user makes a mistake on a computer? These are things we will cover in today’s post.

‘Assume people will make mistakes. Anticipate what they will be and try to prevent them.’

Susan Weinschenk stated the above in her ‘Psychologist’s View of UX‘ post, the inspiration for this series.

Why would we want to prevent them though?

Well aside from mistakes causing users great frustration and pain when interacting with a system, mistakes can be rather costly, particularly in the financial sector where a user might be trading thousands, or even millions, of dollars with one click. It’s imperative when designing the user experience for financial interfaces to make the workflow easy-to-use and error-free.

There goes my retirement fund!

So how do we prevent errors?

The best error message is no error message. What this means is that a system that is designed well will not allow the user to make an error to begin with. The main way we can accomplish this is by predicting what mistakes a user might make, based on knowledge gathered by researching  the environment they operate in and their needs with the system. We can then adapt our designs accordingly to avoid allowing those mistakes to be made in the system.

If the task the user will be conducting is very complex or error-prone, a further approach is to break up the task into smaller steps so that each step can act as a quality gate before the user is allowed to move onto the next. We often see this design solution in online payment portals on retail websites, like Amazon or this donation website below.

One step at a time...

How do we treat errors in the system?

Not like this. Can you read that? Honestly? Even you developers out there (who often are the ones who have the mission of writing these error messages). You are human too —  we don’t talk like that. The first crucial step to dealing with errors in a system is speak in human language! Explain that an error has occurred, what the error is, how the user can correct it and where they can go for more help to fix it. In plain language. When something goes wrong in a system, it’s of the highest importance that the user knows what to do about it.

The below images are great examples of clear, human language communicating to the user the problem with visual cues (symbols and colours) and sometimes even contextual hints as to where the problem went wrong (i.e. a highlighted password field when the password is wrong)

Suggestions of what to do next

Effective colour and symbol usage

Everything wrong is in red. Perfect.

Human language! Yippee!

Simple. Problem. What is it. Do this.

We should also allow users to UNDO actions, such as mistakes they have just made. Ctrl-Z, anyone? It’s been a godsend for me. Users need autonomy within a system and this can only be achieved if the system is so well designed that the user can’t get so lost down a path they can’t find their way back to where they were. Allow them to undo and reverse steps. Similarly the ‘ESC’ key can be used to exit a curtain task that isn’t yet completed, to prevent the damage from being done.

In reality, it is near impossible to create a completely error-free system that guarantees the users won’t make mistakes. But why?

Because people make mistakes and UX Designers are just people.

“If Ernest Hemingway, James Mitchener, Neil Simon, Frank Lloyd Wright and Pablo Picasso could not get it right the first time, what makes you think that you will?” –Paul Heckel

Without sturdy user research, the designer will have a lack of knowledge of the user needs and this can result in an unusable design. That’s why we as designers need more time. More time for research with the users and more time for testing with the users.

At a ‘Lean UX’ workshop I went to last weekend Janice Fraser, one of the founders of the famous Adaptive Path UX consultancy, said rather powerfully in regards to the Agile methodology, “Don’t throw the design out into the world and hope it works. I no longer want that responsibility. We are supposed to get it right the first time, yet the developers get to do it over and over again.”

UX Designers need the allowance of time and budget to be able to test our prototypes on real users before the designs are fully coded and completed for product release. That’s not to say that a design shouldn’t be coded to test if it’s implementable or to test the functioning prototype on a user, but we need time to test the designs before they are finalised.

The problems begin to appear with usability testing

That way we can see what errors the user might run into or what errors are prevalent in your design. And then we can iterate and improve on our designs.

Not enough time?

“The joy of an early release lasts but a moment. The frustration of an unusable system lasts forever.”

Let’s do it right, step by step, and try to design a system that is *mostly* error-free.

————–

Thanks for reading! The next part of the Psych of UX series will be on how human memory is complicated. Until then…

Overall it was an excellent conference with a great group of attendees. The numerous inter-session conversations I had with fellow attendees were as enlightening as the sessions themselves.

Here are my thoughts about the sessions that I attended.

Monday 13th June

HTML5 Boot Camp

This session by Laurie Young and Ismael Celis was one of several focussing on the hot topics of the moment, HTML5 and JavaScript. After a brief introduction to HTML5 and what it provides we got cracking with the exercises.

Working in small groups we were asked to implement a web page that allowed the user to drag an image from the file system into it. The next task was to upgrade it to get the image(s) to persist when the user refreshes the page using local storage. Finally we were asked to use a web socket to send the image to a pre built server which would then distribute it to everyone else viewing the same web page.

There was a reasonably large range of JavaScript experience within the session, however I think most people managed to complete the exercises. It provided a great introduction to several of the most universally helpful HTML5 JavaScript APIs.

Improving Trust in Teams

Rachel Davies’ session looked at how to improve trust in teams.

Split into groups of four we were encouraged to discuss our various experiences of both low and high trust scenarios. Perhaps unsurprisingly most of the scenarios that were highlighted involved low trust. Once each of us had relayed our own trust stories within our groups we were invited to share the most interesting ones with the wider audience.

Afterwards we resumed working in our groups to draw force field charts that highlight things that we believed help to improve trust and those things that hinder it. We drew these up on a flip charts and again shared our thoughts with everyone attending the session.

Finally we looked at one of the forces behind improving trust and what we might do to nurture it.

It was an enjoyable session that has really made me start to realise that there are perhaps more facets to trust than I had previously considered.

At the Extremities of Extreme

This catchily titled session by Julian Fitzell and Jason Ayers was a fascinating introduction to the theory behind wolf pack programming. This technique takes the familiar pair programming, but turns it up a notch, taking collaboration to a new extreme.

I can barely do the concept justice here, but my simple interpretation is that with adequate tool support developers can collaborate without having to be sat around the same PC if they work on precisely the same instance of the code. The tools would allow a developer to see which functions/methods the other people working on the code base were looking at or editing. This allows pair programming to be followed where appropriate, but the navigator can slip off to do some driving if they think of something that will help to remove a block that they have observed that the driver is about to encounter. They also advocated judicial use of spikes to hunt out the quickest solution to a problem.

They had run an actual wolf pack programming session on Sunday which I am now disappointed that I missed.

At the moment the example sessions they have been running use Smalltalk, however my thoughts are about how we might trial these techniques for JavaScript development.

Invited Rant

John Nolan entertained the conference audience with a rant against the term “software engineering”, specifically that:

Software engineering does not and should not exist

He reaffirmed Kent Beck’s statement that:

Software is software

He conceded that:

Software is like engineering

But saying it is engineering is wrong. Instead he introduced us to a different metaphor:

Software is cooking

The examples he provided were very compelling, although even John conceded that he wouldn’t be changing his business card to read Software Chef just yet.

Tuesday 14th June

Unfortunately I missed most of Tuesday’s event as I was preparing for my presentation the following day, which leads me to…

Wednesday 15th June

Web Apps That Shine

I co-presented this HTML5 focussed session with my colleague Adam Iley. The specific context for it was the features of HTML5 that allow up to build web apps.

We introduced the offline support that is provided by HTML5, including local storage and the application cache. Afterwards the attendees paired off and worked at upgrading a n0tr, simple note taking website, to work offline.

The second section highlighted the tighter integration we can now get between a web app and the device it is running on. On mobile devices access to geolocation, and the device orientation is available, whilst on the desktop we can implement drag and drop both within the web app as well as to and from other applications, including dropping files into the page. Again we asked the pairs to upgrade the n0tr app to use some of these techniques.

We concluded by talking about portability and other concerns for building and releasing web apps. The presentation is available online as are the exercises that we ran.

Invited Rant

Jason Gorman’s rant was titled Slow and Dirty.

It was a thought provoking view on our responsibilities as developers with plenty of statistics to help back up his points. When starting on a new project the features come in thick and fast, however over time productivity starts to plateau. On the 8th major release of a major product (no names mentioned) the cost to write or change a line of code was 20 times as much as it had been initially.

Making our software maintainable is our responsibility, and is not something that we should abandon in our quest to keep adding new features to keep our customers happy. We need to be prepared to pace ourselves for a marathon, not a sprint.

Finally, beware the statistical aberrations that seem to have flouted all of this advice and are major successes nevertheless. Just because your great aunt smoked 60 cigarettes a day and lived to be 103 doesn’t mean that to give yourself the best chance to survive to 103 means that you should smoke 60 a day.

Specification By Example: By Example

The final session I attended was run by Lasse Koskela. Lasse asked us to split up into groups of three, then handed out an index card to each group that specified a requirement for a particular software system. Within our groups we needed to capture the specification by writing or drawing out the various examples we could think of.

My group was asked to produce the specification for an email verification system. We sketched out the interaction between the server and the user, defining 5 different scenarios that we could think of, one of which covered a hacker.

Two members of each group were asked to switch over with people from other groups. The remaining person on each group was asked to explain the examples they had drawn up to the new members, and we were asked what improvements could be made.

Finally everyone changed groups again, moving onto a requirement that none of us had worked on before. We are asked to review what had already been done, then start afresh and come up with our own examples.

Overall the session went very well and it was interesting to see how much would be achieved in a very short period of time by sketching out the examples with tight collaboration between all the members of the group. There was a warning flag though that the lifespan of the examples that we created was limited as there was contextual information that was only available to those who were involved in the conversations surrounding the creation of the examples – a little more structure might be necessary if these are to persist over a long period of time. Nevertheless this was a technique that I’ll be trying out at some point soon.

I spent a very informative time last Wednesday at the first day of this year’s ThoughtWorks Live event. The conference was videoed, so I guess TW will be making the conference material available in due course. Here’s my take on what was presented:

Adaptive Leadership: Accelerating Organisational Agility

Presented by Cyndi Mitchell, MD of ThoughtWorks Studios, she did a great job, apparently stepping in for Jim Highsmith at the last moment and presenting a good overview of current thinking on how agile principles can be applied to more than just the development and project management functions.

She covered goals and constraints, highlighting the choice a business should make between responsiveness and efficiency, suggesting that one should be the primary goal and the other a constraint. She contrasted Google, who’s primary goal is responsiveness, with Walmart, where the main goal is efficiency. She went on to talk in detail about the “Core Adaptive Leadership Model”, the role of agile leaders in organisations that are striving to be responsive and how, just as sometimes it’s hard for developers to adopt agile principles, so it also can be for leaders.

She discussed both Doing Agile (the adaptive leadership actions of speed-to-value, do-less, quality and engage-and-inspire) and Being Agile (the need to transform leadership mindsets to be adapting, exploring, facilitating and riding paradox). I liked the “Riding Paradox” ideas the most – the thought that an adaptive leader should move towards AND rather than OR leadership – not making decisions based on one thing OR another (Scrum OR Waterfall, velocity OR quality for example), but finding a way to take the best from each.

There’s an increasing amount of good material appearing in this space (eg. Jurgen Apello’s Management 3.0 and Jim Highsmith’s paper itself) and these ideas are a useful addition.

Done Agile. What Next?

Presented by Dave West, currently with research firm Forrester, Dave took some stick from the audience when he confessed to being partly responsible for developing RUP in a previous life, but he recovered quickly to present a highly animated and entertaining talk on where to focus once you have the agile development process working well.

His take on Continuous Deployment, based on research by Forrester into many organisations, looked at the whole process from initial idea to release in production. He introduced the idea of the Water-Scrum-Fall process, suggesting that most organisations, even ones that do agile development well, continue to be far from agile either in the up-front requirements capture and project definition phase, or in the final deployment to live operation phase.

His suggestion for tackling this is to start at the Ops end of the process, because, while still hard, it’s easier to do than addressing the front end. His assertion is that if you fix the back end so that deployments are simple, fast and can be done whenever the business wants, that will force the front end requirements stage to adapt. The movement towards extension of agile development practices into the ops arena (the DevOps movement) is central to the concept of continuous deployment and a recurring theme of the conference.

Amongst anecdotes about doors falling off cars and x-ray machines, Dave stressed the need to scale agile, fight Water-Scrum-Fall and aim to continuously deliver.

Implementing Beyond Budgeting: Unlocking the Performance Potential

Presented by Bjarte Bogsnes from Statoil, for me, this was the unexpected gem of the conference.

Bjarte introduced the idea that large corporations (and by inference, therefore, any organisation) can cope and indeed thrive without an annual budget process, or even a travel/expenses policy and budget. He highlighted the absurdity of setting an annual budget and dishing out large pots of money at the start of the year, when in fast moving businesses, it’s hard to guess what’s going to happen next month, never mind in a year’s time. What Statoil have done at the business level is bold, agile and sounds to have been very effective. He talked about management styles applied to Theory X and Y people and how traditional management doesn’t work in a dynamic environment.

Over a period of years, Statoil have moved to embrace a management style that recognises rapid change is inevitable and the way to deal with it is to trust and empower employees (sound familiar??). They have also moved away from traditional budgeting process to focus on just-in-time decision making on expenditure. They trust people to do the right thing rather than implement policies to enforce it (eg. No travel policy), then do something about the few who try to abuse the system. They have broken the link that exists in most organisations between targets, forecasts and resources – sure, they still use these, but they measure and track them relative to their competition, not in absolute terms and adapt them whenever they need to.

Statoil have taken the idea of Balanced Scorecard, which many organisations use and tried to find a business differentiator. In their case, they ripple this through the organisation through “Ambition to Action” plans – each group in the organisation identifies its vision and strategies, then creates metrics for each and identifies actions needed to meet the objectives. A recent innovation is that each part of the organisation (and individuals as well I guess) now updates its Ambition to Action when needed, and not necessarily on an annual basis, so some get updated more frequently and others less. Real food for thought here, I rushed out and ordered Bjarte’s book as soon as the session was over!

Guest Speaker, Scott Durchslag, President of Expedia

Scott joined Expedia a few months ago and has the job of re-invigorating the brand and positioning it for future growth. He talked through his approach and the challenge he has set the organisation to move to a release cycle of 2 weeks for new features and products.  His approach has been to create a bold vision and mission statement – that Expedia should delight its customers and become a trusted source for all their travel needs. He highlighted the need to break down existing organisational silos and mental models, to focus the organisation on realising change and highlighting what will happen if change doesn’t take place.  Again, he stressed the need for responsiveness in the organisation and how continuous deployment can help that goal.

Implementing Continuous Delivery

Presented by Martin Fowler and Jez Humble and based on Jez’s book Continuous Delivery, this was a shortened re-run of a seminar I attended at Thoughtworks a couple of months ago. It was good to hear Martin’s take on the subject and it broadly validates the approach we are trying to take here in Caplin. What’s the difference between continuous DELIVERY and DEPLOYMENT? Simply that while that aim of both is to be in a position at all times to be able to deploy working software, with continuous deployment, that final stage is automatically done. Another question to ask and that will focus attention on continuous delivery is “How long would it take your organisation to deploy a change to one line of code?”  Our target at the moment in Caplin is within 2 weeks, companies such as Flickr appear to be able to do it much quicker.

All in all this was a useful day with a number of thought-provoking sessions. I was unable to attend the second day, but my colleague and our Build Manager, James, did go and presented a brief session on our use of Go, so maybe he will post some impressions from that.

Now I’m off to talk to our CFO about budgets…

This is an interesting post by Anders Ramsay.

I definitely think design agility is an important skill, I think it goes without saying that if you do not have agility then you are not agile, but I also think that design ability is also just as important for agile teams.

Sometimes when we need to produce ‘presentable’ wireframes to show a client complex interactions in an animatic we’ll spend some time polishing them up; but lately we have just been scanning in rough sketches. It makes it much more obviously ‘unfinished’ and definitely leads to looser design discussions.

Often when we need to resolve design issues that come-up ‘in sprint’ we will have a quick chat with the team and produce a 10 second sketch to facilitate the design solution, job done. This is design agility to me. It does depend on the development team having at least some design ability though – luckily at Caplin our devs are all cool techreatives at heart.

On design collaboration…

Obviously collaboration is a fundamental part of the design process, but this doesn’t mean that the whole design process needs to be collaborative.

As Tim Brown of IDEO discusses on his blog about ‘Design Thinking’ being a problem solving approach, I think the same is true for UX. There are the two sides of the process, divergent (creating choices) and convergence (making choices)… Analysis (breaking problems apart) and synthesis (putting ideas together).

The skill for ‘agile design facilitators’ is knowing when and where to collaborate. When to ask for input from subject experts, when to gain insights from users and when to open up for multiple inputs. But also knowing when to downsize and focus on synthesizing the design.

Collaborative design doesn’t need to lead to compromised design (nicely pointed out by Andy Rutledge) but both the designer and the organisation need to cultivate a culture of design and trust in design, the seven core perspectives offered by Brett Lovelady from Astro Studios distills this idea nicely.

As Twyla Tharp (author of The Collaborative Habit) says…

Collaboration can be internal – an act of listening to others and then having a silent, private conversation with yourself.

Agile attitude – yes of course but with design agility must come design ability across the organisation.

I missed the start of SPA2010 on Sunday, I knew it was going to be a heavy week and I needed some time for the family Sorry Phil/Adam.

Monday started with the opening plenary, I think it was good, I’m sure it was… it’s just that I was a bit distracted thinking about our impending workshop – would it work out?

Persona Driven Development – Can it work for you?

Phew! I think the answer is YES!! the Workshop was well attended with about 20 participants. We introduced Narrative Journey Maps (NJM) and how to create them. The everyone had a go. Prezzi the zooming infinite desktop type format worked well (thanks Sarah) and the materials seemed to be fit for purpose.

After the first exercise we introduced personas and the re-ran the scenario walking in the shoes of the personas on a ‘Discovery’ session. This generated lots of ideas and demonstrated how personas can focus effort and creativity and also unify a teams understanding of the motivations and needs of users.

Feedback on the workshop was very positive. Participants liked the narrative storytelling elements of NJMs and how they visualised a complete interaction flow, a number of participants mentioned that they could think of situations at their own organisations when they would experiment with them.

Most participants were aware of personas but had no direct experience of using them, again the feedback was positive and the proof of the power of personas was evident around the room and on the walls with all of the creative ideas and solutions that were generated.

WOW time to relax and have some lunch!

Pinocchio: on becoming a Lean Leader

This session was run by Portia Tung and Pascal Van Cauwenberghe. I wasn’t sure what to expect but as the story of Pinocchio was retold in whiteboard imagery one thing became clear – this was going to be fun.

By pulling examples from the story and focussing on the negatives and the positives (bad decisions made by Pinocchio made his nose grow)… by being strong and brave (and making good decisions) he was able to become a real boy etc.

Portia and pascal quickly took us from fairytale into corporate philosophies which was an exciting and demanding ride.

Here are some key takeaways:

Lean Leadership Tools:

• Visual controls – Use simple visual indicators to support Flow and Pull
• Standard Work – Adhere to work processes
• Daily accountability – Use visual controls to improve focus and drive improvement
• Leadership discipline – Set clear expectations and maintain focus

Tools of a learning Organisation:

• Nemawashi – Make decisions slowly based on consensus, implement decisions quickly
• Hansei – Relentless reflection
• Kaizen – Review regularly to establish a stable process and make incremental improvements

All of the above is guided by the long term philosophy: Grow and align the whole organisation towards a common purpose greater than purely a financial reward.

This was a fast paced journey that left me wanting to learn more about everything, but my little wooden head can only hold so much.

Apparently there is a whole series of Agile Fairytales, Pinocchio is the first in a new series of Lean Fairytales – go check!

Retrospectives Refactored

I haven’t had a chance to attend to many retrospectives I felt they were an excuse for developers to sit navel gazing. The few I have been to were actually very constructive and a great way to reconsider ways of doing things and set up new ways of doing things to try out next time.
Rachel Davies made the case for retrospectives as a key part of the ‘Agile way’ it was a great opportunity to learn from other organisations on how they run retrospectives and we all shared our good/bad experiences.
I think the key takeaways for me were:

• To ensure that there are actionable outcomes from retrospectives

• Only take on 2-3 actions for the next sprint

• Assign the actions (ideally people should volunteer)

• Allow TIME during the next sprint for the actions to get done

I also liked the idea of not having a retrospective after each sprint (as it becomes part of the mundane) and maybe having a bigger/longer retrospective after a big feature release of tranche of work or after every other sprint.
Taking these bigger retrospectives off-site was also seen as a good thing.

End users as software engineers – Good idea? Yes but no but…

The theme here from Helen Sharp and Lucy J Hunt was that with advancements in users technical knowledge and the development of simpler tools for software development… should end users be developing software?

There were so many pros and cons around this issue that I didn’t reach a clear verdict in my own mind, and I think this was the purpose to expose this conundrum.
You could argue about empowerment and that if a user has created some little software tool to help them get their job done then where is the harm in that.

But you can counter that there are many risks that this exposes. Who is responsible for supporting this software, the hidden costs, liabilities and data loss. The fact that only one person ‘knows the code’ etc. are all up for consideration. This is all before we got on to discussing the professionalism of software development and the unmaintainability of badly written code.

Some of the tools Helen and Lucy used in this workshop can be discovered on the Voluntary Service Overseas (VSO) website within their VSO Advocacy Toolkit.

When an end to end acceptance test fails, the failure could be due to any one of a large number of source lines or expectations changes across a large body of code.  Debugging may be quick, but often isn’t.

Small tests run faster too! While a typical small test may take 10 milliseconds to run, a large acceptance test may take twenty minutes.

Just a small back of the envelope calculation tells us that if a developer checks in twice a day and saves an hour each time because potential issues had been found before check-in with fast small tests, and the faster feedback, or has reduced their time spent debugging – that is two hours a day per developer that could be put to better use.

2 hours a day * thirty developers * two working weeks = 600 additional hours per two week iteration available.

This is equivalent to adding seven and a half developers to the team!

What value do you get from tests of different sizes?

Ignoring this testing just generates projects which will fail – not may fail – will fail, categorically will fail!

There are two sets of tests that are critical here…

Good unit test coverage and a TDD approach to development ensure that the rest of the organisation is supplied with product that works as developers expect it to.

Component tests and functional acceptance tests ensure that the product does what the product owner expects it to.

• Practically, the only way to do solid testing on new features is to have a stable product.
• Practically, the only way to assure a stable product is to either have solid regression testing on each release or to not make any changes.
• Practically, the only way to make sure that adequate regression testing is done is to automate the regression tests (unit, component, functional).

Without these tests in place, iterating quickly places an impossible to meet burden of verification demand on the testers and product owners, which just gives you a fragile process not an agile one.

Is your process Agile or Fragile?