“They say the world has become too complex for simple answers. They are wrong.” Ronald Reagan

Behind the scenes, today’s products and services are very complex. As consumers demand ever improving customer service and more advanced functionality the complexity only increases. The challenge for design teams grows and companies struggle to create the increasingly important illusion of simplicity.

Complexity presents itself in many forms:

1.       Technology e.g. multiplatform, new technologies and platforms

2.       Legal e.g. FSA regulations, EU Directives, data protection, accessibility

3.       Stakeholder e.g. multiple teams, differing objectives

4.       User e.g. context of use, user needs, expectations and abilities

5.       Content e.g. quantity of data, specialist data

6.       Interaction e.g. balance between intuition, learnability and control.

As designers, we know it’s our job to help bring design projects through this complexity. I’m reminded of a great quote (by whom I don’t know):

“Sometimes God calms the storm, sometimes He calms the sailor“.

It’s the designer’s role to do a bit of both. We work in a highly collaborative way to calm ‘the sailor’ and make sure the team is able to make informed decisions. We also work in a user-centred way which enables us to calm ‘the storm’ by designing content and interactions appropriate to the user and the commercial context.

Sometimes interfaces we design are beautiful, some are purely functional some are invisible. We challenge ourselves to deal with complexity so that the end users don’t have to.

That’s great design.

(Thanks to Lenny for use of his image  http://www.flickr.com/photos/lenny_meriel/3587338182/in/set-72157608595536634 )

My perspective comes from managing a number of software products and software development groups through the transition from waterfall to agile approaches. In these roles I created and owned the product concept and was responsible for its realisation in the delivered product. And I found this much easier to do in agile rather than waterfall projects.

Earlier integration and test helps create better user experiences

I have seen several large waterfall projects crash and burn because components were integrated and tested far too late. By the time serious problems were found the release deadline was looming, most of the budget had already been spent and the people needed to resolve the problem had moved to other projects or even left the company.

The imperative on agile projects to "deliver working software frequently" should drive them towards frequent (continuous?) integration and test. So they can catch problems before they grow too big and while they still have the time and resource to do something about them. This also requires some leadership within the agile team to prevent difficult tasks being continually pushed into later iterations.

I found this early integration really valuable in creating a consistent interaction style and visual style across a large product, as components produced in early iterations could act as exemplars for later components. And it is now giving UXers the chance to inject some 'undercover' or 'guerilla' user testing to expose usability and usefulness issues, and get them resolved earlier.

To really drive this home UXers should push to get basic user testing included in their team's 'definition of done' and push to get the challenging user journeys built in early iterations.

Self-contained teams produce better products faster

For me, the second great benefit of an agile approach is having a self-contained team with all the skills needed to create the product and the authority to make its own decisions. This saves so much time and avoids so much frustration.

Many years ago I worked in an organisation that had separate teams of testers, developers, architects, product managers, analysts, writers, etc., with all the delays, whingeing and brick-throwing that you might expect. Bringing all these people together into agile teams has been painful, but ultimately incredibly rewarding. And bringing UX people into the mix is painful, but can bring the same rewards.

The product roadmap provides the big picture

Common complaints about agile are the poor quality of the incoming stories or use cases and the lack of a clear overall vision to tie them all together. In most of my jobs I was lucky enough to be able to maintain a longer-term roadmap for my products. And I saw the benefits this had for projects.

The product roadmap set out a clear vision for each new product or release. What it would provide to the business and to our customers, what it would contain, what design principles would guide it, etc. So when it came to building a new feature, while there was still detailed design work to do, the purpose of the feature was clear and its place in the big picture was clear.

The roadmap also helped to drive through broad improvements to usability, performance, reliability, etc. If all you have is a backlog of functionality-focussed stories, these vital efforts too often get squeezed out.

So UXers should push their way into the product planning process, or push to create one if none exists. This is where you get to do your design research and concept design, and where you get to create the big picture that carries through the project.

Agile does not mean 'no documentation'

The Agile Manifesto states that "we have come to value … Working software over comprehensive documentation." I heartily agree with this. When you are creating a software product or system, documentation is a means to an end. And working software is that end.

But somehow, for some teams, this has been warped into no documentation, no specifications, just code. As well as leading to the lack of a big picture that I described earlier, this also cuts the legs out from under the UXers on the team. As Hannah Donovan has said, "Your super power is that you can visualise things in your head and you can draw them." If we can't draw concepts, service blueprints, storyboards, wireframes, illustrations of design principles, etc., then how do we 'talk' to the rest of the team. Do we just wave our hands? Or try to explain everything in a tweet-sized story?

So while UXers should not expect the rest of the team to wait while they create a complete and comprehensive specification of every aspect of the design, UXers can and should produce drawings to communicate both the big picture for the product and the more detailed design of specific components.

A good way to think about this is the transition from always using a language like UML to create a complete specification of a software product before building anything, to using UML as a sketching language to help team-members communicate their design ideas, while they are building a product.

Understanding the UML as Sketch idea is a good way to understand and explain how UX outputs can fit into an agile project, and how UXers can make them in bite-sized chunks.

So …

While this is a personal take on agile and UX rooted in my own experience rather than any research, conversations with Johanna Kollmann and others from Agile UX Meetup suggest that I'm not completely wrong.

What do you think?

For me the most interesting insight was that unless the primary user lives alone, their tablet is likely to be shared with their partner, children and visiting friends. NN/g concludes that "Tablets are shared devices" and that when designing apps for a tablet "you should assume that you're designing for a multi-user device."

Yet few tablet operating systems provide good support for shared use (driven by its need to control access to sensitive business data, the Blackberry Playbook is a rare exception). And this can lead to significant problems for users. Young children accidentally change settings, delete work emails and reset the game scores of older siblings. Teens move apps between folders, access age-inappropriate games and media, and use stored account and payment information to make unauthorised purchases. Partners must frequently log in and out of each other's Facebook, Twitter, Google and other accounts.

Working your way through these sharing problems is hard work for even the geekiest of us. And while some apps do provide simple ways to control access to multiple Facebook, Twitter and eMail accounts, users must learn the sharing features of each app and create a separate profile in each one.

This again demonstrates how important it is to investigate and understand people’s real behaviour and contexts of use when designing for new platforms.

So when we design tablet apps, we must consider carefully, whether and how to support shared use. Will users each want their own settings and data? Will adults need to protect some sensitive data from their children? If your app connects to a website or web service, will different users need to connect to different accounts? If you do need separate user profiles, how will you store and how will your users manage them?

NN/g's research and the multi-user support within many apps, suggest that better support for shared use should be a priority for tablet operating systems. The access experience could be very simple: tap your name and enter a password/code, or even just show your face to the camera. And while each app would still need to decide how it handles multiple users, standard APIs and common interface guidelines would make life easier for designers and developers. And most importantly, make the experience of sharing more simple and more consistent for users.

We are UX designers not UX artists. We design for a purpose, but that does not mean that creativity is not a large part of what we do. Design via a UCD process supports creatively with freedom and low risk if implemented properly. In the context of the business objective and the users’ needs, the UCD process allows us to inject creativity into the design process with little risk of creating something that has little or no value to either the business or the customer. UCD also supports collaborative working with a multidisciplinary team, increasing the creative gene pool. UCD is user-centred, not user-led.

Why is this so? First, we are afforded a true understanding of what a business is trying to achieve via business research, establishing their objectives and goals and agreeing what success looks like. Second, we also acquire insights into the users’ context via user research. User research doesn’t just tell us what the user thinks they need (as users are not designers) it provides us with the stories that we use to not only solve the problems they are facing, but to innovate in a way that will extend the solution beyond what they could possibly imagine. All of this is done while still supporting the goals and objectives of the business.

Following on from the research phase is conceptualisation. At this point, user experience consultants are free to create and express their creativity by producing many diverse, off-the-wall, way out solutions, without restrictions. The freedom is implemented without risk. This is possible because as a result of the research stage, we will have created artefacts that that are essentially used as concept filters. These filters are used to determine which ideas will create solutions that will extend beyond usability; not just create designs to best practice or standard convention. Those artefacts include, but are not limited to, personas, scenarios, business objectives and goals, and prioritised user requirements. Also in the filter mix is foundational knowledge, as UX experts that will include understanding of human behaviour, emotion, and physical and mental limitations of users.

These filters are used to select and extend the best, most innovative solutions. This part of the process, pre-design, greatly reduces the risk of implementing a creative phase between research and design that doesn’t limit creativity but ensures the solution solves the problem and isn’t just creative for the initial wow factor.

So in reply to Steve’s assumptions about user centred design:

• User insights cannot predict future demands, but creative people can easily address this within a UCD process that includes collaboration of a multidisciplinary team.
• UCD does not stifle creatively, but by significantly lowering the risk within a design process allows creativity to flourish, but not run wild.
• The process is not user-led; it is fuelled by user insight. Users are not designers. The products that don’t benefit from the insights provided by user research are notoriously bloated by unnecessary user requirements- making them more complicated and ultimately more expensive and prone to overruns.
• User-centred (not user-led) only leads to sameness if the practitioners aren’t very good at their jobs. You should not confuse poor implementation, skill, or knowledge with what you believe is poor methodology.

Only a bad workman blames their tools. So ultimately, I agree, a user-led process cannot create innovations, but true user-centred design does.

It is no wonder then that registration forms try to make sure details are captured correctly. But how to do it while still preserving a positive user experience? Registration forms basically represent a barrier for people to be overcome before they can do what they actually want to do – finally use the website!

Here is how others have tried to handle this (with varying success):

Confirming entry

I frequently see a registration form that has duplicated Email or Password fields. Now, this is a little bit annoying, especially if both Email and Password need to be confirmed (as below).

In the above example, the person’s interaction flow is significantly interrupted by having to answer two identical questions. As per Don Norman’s model of 7 Stages of Action, answering each single question on a form is a small diverting action on the person’s journey towards accomplishing her goal.

Disabling copy & paste

Harry Brignull wrote about a registration form that does not allow pasting into the ‘Confirm email’ field. Quite creative, but I agree with Harry that it could feel patronising, especially for the more tech-savvy people (who know how to copy-paste). On the other hand, it prevents people (hopefully) from simply replicating a typo made in the first field. And typos are arguably one of the commonest kinds of incorrectly entered details. Now let me ask, why do most websites actually use the wording ‘Confirm your email’? Let’s use ‘Re-type your email’ instead, and it might not be necessary to awkwardly disable standard system interactions like pasting.

Repeating key details before submit

A more elegant solution is not to display the second confirmation field at all. But how can businesses eliminate the eventual errors on forms then? I quite like concept prototypes created by Jonathan Knoll and Russ Unger, that repeat the entered email just before submitting. Jonathan and Russ have produced multiple variants, but variant 5 (picture below) is my personal favourite. It puts the entered email within the person’s locus of attention which is at that point in time on the Submit button.

Unmasking passwords

What about passwords, that are by default masked on most forms (even at registration)? First of all, I believe masking a password does not bring any value in most usage scenarios. Nielsen calls for the death of masked passwords, and I am happy to agree with him. However, as opposed to offering a checkbox to mask the password, as he is suggesting, I think the way to go is actually offering a checkbox to unmask the password. After all, in most contexts security is more important than interaction efficiency.  MailChimp is doing this already, and based on a recent live demo of FontDeck, it seems like we will be seeing this pattern more often.

A pattern for unmasking passwords is also frequently used on mobile devices. This is due to the lack of tactile feedback provided by touchscreen keyboards when inputting a password. Moreover, people also cannot rely on their motor memory (remembering the finger movements like in touch-typing, as opposed to the actual password characters). People often utilize the motor memory to enter passwords with little conscious effort, and this does not translate so easily to touchscreen keyboards as visual identification of keys is needed.

Most mobile interfaces support people by revealing the last character entered for a short time and then masking it, thus giving people the necessary feedback. I am not aware of any website doing the same, but it might be a solution for standard monitor-keyboard setup too. On the other hand, the utility of this short-time revealing is debatable since most people type so fast that revealing the last character and masking it with a time delay is very difficult to implement seamlessly.  Try it for yourself - here is an example of automasking.

Inline validation

Another powerful weapon against incorrect entries is inline validation. Validation can only catch a small proportion of specific errors, but it is generally a good approach since people are notified something is not quite right before they hit the Submit button. Therefore it eliminates the need for the dreadful error messages. “Fatal error - you have not filled in all the details!”. “Oh my god, fatal error - someone actually died!” screams the user in horror.

There are multiple ways of implementing inline validation. Luckily for us, Luke Wroblewski put a few validation variants to the test. Based on his study, validation ‘after’ (after the person indicated that she was done answering a question by moving on to the next one) is the winning option - both in terms of efficiency and satisfaction.

So what?

Incorrectly entered details in online forms are a frequent problem that can cause a lot of hassle down the line. However, when designing forms, make sure you use a sensitive approach to minimising those errors and do not make the people do all the hard work for you.

I would love to hear about your tips for minimising errors in forms.