dancingmango

In the real world, when I get an application form I’ll flick through the pages and have a look at what is required. I can choose which fields I complete in whatever order I like. If I want to take a break half way through I can. I can complete it when I like and how I like.

So why aren’t web forms like that?

The usual format for a web form starts with some copy that describes the form (which people skim through at best). The user clicks to the next page and the form commences. There may be a step indicator showing progress through the form, but almost certainly progress through it will be linear. You have to complete each page before progressing to the next. If you are lucky you’ll be able to click to previous completed steps. But the experience is nothing like a real-world form. And when was the last time a real-world paper form “timed out” half way through, demanding the user to start over again if they left it idle for ten minutes?

The web forms we see today are a relic of their tecnological past. There is no reason why they must be linear, (and if there is logic in the form, there is no reason why the user can’t explore the different routes - you do that with a paper based form). There is no reason why the user can’t click to whatever page in the process they like (just like with the paper form). There is no reason why a page must be completed before progressing to the next. There is no reason why the form should time out and forget everything the user has entered. Fields can be saved as they are completed against an anonymous user, until the user wants to provide personal credentials.

Bottom line - the web has moved on. Instead of reflecting technical constraints of yesterday, it can adopt more real-world metaphors. But do we have the courage to start introducing new paradigms? Are users, information architects and usability experts so ingrained with broken web metaphors that they will shun a new model, (a real world model) of completing a form?

So here’s a rough example. It’s an application form for a savings account. Ignore the content, field labels etc, it is more the model that is illustrated.

1. The user can move between the sections (tabs) to see the fields that are required. There is clear feedback on each tab that it has not been completed. The “Direct Debit” section is optional hence no indicator. The ability to save the application is seperate.

–

2. The user selects “Bank details”. They’ve not filled out all the fields on the first tab “Personal details”, but it doesn’t matter. There is clear feedback that this tab is yet to be completed.

–

3. The user clicks right through to the confirmation tab. There is nothing to confirm so the page remains blank, with a prompt to fill out other sections.

–

4. When sections are completed the indicator on the tab changes to show completion. Here the user has completed step two ahead of step one.

–

5. Finally, when all sections are completed the user can review the entire form.

I’m not saying this is perfect, it’s a start. A start to re-thinking the way we design forms on the web and think about modelling them on real world behaviour instead of technical constraints of the past.

In the corporate webspace most design is little more than mediocre. Interaction design has changed little since coporations first realised that this is a channel thery should exploit. Web 2.0 is slowly making in-roads with basic use of Ajax functionality, but there is nothing that is really breaking the mould. Despite its infancy (for most organisations ‘e’ is barely 10 years old, Amazon, the granddaddy of eBuisiness is only 13, born in 1995), conservatism rules; the corporate web is just not growing up. It would be easy to blame the technologists for being risk adverse- for having invested in architectures and frameworks that do not allow innovation. REST and all that declarative goodness may be great, but of little interst if you have invested in a propiertary framework that does not support it. But the business is also responsible for tardy innovation.

It doesn’t know what is possible. A miss-understanding of accesibility clobbers rich interactions; “no javascript” becomes the mantra, despite the guidance being “provide alternatives” and progressive enhancements making basic and rich interactions possible with the same code. And maybe as usability testing becomes the norm, and testing concepts with consumers throughout the product lifecycle is baked into the process, this is acutally the final nail in the creative coffin. Let me explain.

When you are developing new features or propositions it is only right that you should conduct market research, talk to your customers and get feedback to refine your ideas. But sometimes you need to ignore what you are being told and challenge the perceived wisdom. Imagine the scenario; you are developing a social networking site. You recruit a bunch of consumers to participate in user testing sessions. They match the socio-demographic profile of your target audience, they use the internet more than five hours a week. You let them loose on your concept boards and prototype. They like what they see, they like the blogs… but commenting? The feedback is that none of them would leave comments. So what do you do? Kill the commenting on the basis that the users who matched your “average” profile would not use this feature.

I’m not saying that if you are building a conventional, transactional experience; a retail shop, a financial services provider, you should not test the proposition with users that match the target profile. But beware that they will steer your thinking into the realm of the ordinary, the expected and the average. Try testing it with trend setters, gamers, teens, mybe even anti-personas to push the boundries and harvest real innovation insights.

And maybe testing the proposition is not needed at all. But don’t leave the design to the comittee or the accountants. Sometimes it is more important to have a real visionary driving the product development. Apple is a great example of this, no more so than with the iPhone bounce. When you scroll down a list, when you come to the end, the last item “bounces”. Where’s the “business value” in this? Isn’t this gold plating in the extreme? The development of this bounce will not have been for free, it will have come at a cost. This could have been a financial (more development effort) it could have been at the expense of another feature, or it could have been time. In most organisations this would not get get through the design by commitee. Apple can do such great things with their UI because they’ve got a visionary at the helm who understands the importance of good design and is passionate about it, and their customers become to expect it.

There once was a time that on Christmas eve that I’d be crawling round the pubs getting the worse for wear.  Older and a maybe a little wiser; I’ve just committed a major fraud - I’ve downed the sherry, nibbled at the carrot and filled my daughters stockings with presents - Santa exists.  Honest.

And now I can’t help myself.  I check my mail and scan the blogs I subscribe to and I read something that makes me nod my head in agreement - Robert Hoekman laying into user centred design.  He is so right - most projects don’t have the time for the luxury of doing user-centred design properly.  That is not to say that it can’t be done.  Thirty days to develop personas?  How about thirty minutes?  You can be agile and do user-centred design, at ThoughtWorks we do it all the time.  I’m looking forward to his follow up posts.

So only 1% of google searches use “advanced search”. Is this because the word “advanced” (especially in the world of IT) speaks of complexity and language that only people in the know understand. Anders Olausson suggests if it were labeled differently, “easy search” or “better search” (because that is what it actually is) more people would use it and the result would be more efficient searching. There’s a lesson here when labeling functionality and features. All to often the project team in development will refer to something by its technical name, and this will manifest itself on the user interface. Yet if these names are not those of the users language this will at best result in user annoyance, and at worst result in the feature being unused.

Call it a pattern, a heuristic or a rule of thumb. A fundamental one of those to ensuring usability is consistency. This may be external consistency - for something behaves in the software in a similar way elsewhere. A good example might be the ‘x’ button in the top right hand side of an open window. It is universally a call to action to close the window. If the designer created a button labelled “C”, and placed it on the left hand side this would result in confusion. It is not consistent with the users’ expectations from using other applications. The second type of consistency is internal - do things behave in a consistent manner throughout the application? This may be both in behaviours (e.g. buttons with the same titles perform the same action), and in look and feel - a website has a visual identity and coherence, assuring a continuity of experience.

There may be examples of where internal consistency is not possible. For example a brochureware site that uses a third party for fulfilment or payment. Paypal is a good example of this - the user is taken out of the shopping experience and into a paypal experience. This can be successful if there is clear signposting and use of the paypal imagery on the shopping site to assure the user.

So what happens when you have a large, legacy website that you acknowledge to be pretty poor in the usability front and want to introduce new functionality, or want to rebuild it. If you play the consistency card too strongly you may continue to be consistent with the old design and behaviours. This begs the question, is it better to introduce something that is internally inconsistent, but fundamentally better? This becomes even more an issue when you look to rebuilding your site in an incremental fashion.

As an information architect I can help you design your site architecture - the look and feel, navigation structure, user journeys etc., but this will probably be in its entirety. To build this new site will take time, and assumes a “big bang” whereby a completely new site will be (re)launched. Yet there are probably business imperatives to fix specific areas. If we build in an incremental fashion, and take the agile approach of focussing upon delivering business value, we are not going to have a fully redesigned site to go live with. We are probably going to have (for a short while at least), some parts of the site that are new and some that are old.

Going back to my original question, we can either build this to be consistent with the old site, or do something tangentially better. If we do the later it will probably be significantly inconsistent from other parts of the site, or the original parts of the site. It is in this scenario that I am inclined to throw away the consistency pattern. You may have internal inconsistency if you have a clear roadmap to throwing the old and the new functionality / design is proven to be usable, accessible and intuitive. With this the case, the interaction behaviour and visual identity of the new functionality must become the benchmark to which future functionality is consistent with. And you must clearly signpost to the user what is going on; customers will generally be forgiving if they understand that the changes are in their interests.

It sounds clichéd and old hat, but it is true. Truer now than ever before; the web is an enabler for new ideas. It provides you with the tools for disruptive innovation. Sadly for too many organisations it has become a hindrance.

A recurring theme with many organisations is the length of time it takes to take an idea to market. Especially in retail financial services, where you would expect lead times to be short it is not unusual for innovations to take a year to implement. This seems crazy, it’s not as if there is a physical product to manufactured.

So where are the hold ups? More often than not, they are rooted in the organisational structure. Innovative products often cross business boundaries; whilst customers only see the a single brand, different product teams only see what they are responsible for. They have own objectives that often conflict with other parts of the business; gaining agreement and consensus across all parties can often be a time consuming and painful experience that slows and often kills innovation.

Then there is the technology. Changes to systems have to be scheduled (along with every other request). Unproven ideas are put to the back of the queue. The business starts to perceive IT as a hindrance rather than an enabler and lines of conflict are drawn up.

Channel is the next hurdle to cross. Typically a face to face channel or telephony will be easiest, but getting something on the web? Now a new area of the business needs to be involved, the Internet Channel Team who interface between the business and IT. They’ve got to design web pages, get the creative done, produce requirements for technology to build (and schedule into deployment for which the dates are even further into the future), do usability testing… Long lead times are inevitable.

And then, before the innovation sees the light of day, someone new comes in to rationalise the product portfolio, the innovation doesn’t quite fit in with their new priorities and it is quietly ditched. This half hearted attempt at innovation has taken a year, cost in excess of a million and has come to nothing.

There has to be a better way.

There is. Do things at speed. You can start by sticking some amphetamines into ideation phase. Someone’s got an idea; identify who has a vested interest in it succeeding (or failing) and get them into a room to thrash it out. This doesn’t need to take long. Workshops are best limited to 90 minutes at a time (after that people get Blackberry withdrawal symptoms and loose interest). But if all the stakeholders are geographically dispersed, a structured day’s off-site might be the best solution. Avoid letting people dial in or video conference, this is one meeting where people have to be there in physical presence. Also avoid having too many people in the room, especially when forming ideas (there is a trade-off between having the right people and too many people to make the process unmanageable). Start with the users, the customers, the people whose lives will be changed by the idea. Scribble out personas -describe who they are, what their goals are, the perceptions of your company, of technology. Print out pictures of people that represent the personas, rip out photos from magazines, anything to bring them to life. As the idea takes shape, turn it into pictures. Draw out the customer experience. What would the persona do at each stage. Far better to do this than write it down in a document that can be open to interpretation. Illustrate the touch points. What does technology need to do. (Can we be pragmatic and use roller skate implementation rather than getting bogged down in an integration quagmire?)

Now is where it gets interesting. There once was a time when you would need to invest time and money into producing a heavyweight business model and business case for the innovation. You still need a business case, but at this stage it probably doesn’t need to be too robust; make some basic assumptions then test it. All too often business cases are built on flaky assumptions; build something quick, test it and get real data to build your models on. Again, this is about doing things at speed; a couple of weeks after the first workshop there is no reason why a small team of developers can’t be actually building something to bring the idea to life. So the team is using Ruby on Rails to build a proof of concept. There may be disquiet that this doesn’t fit into the current technology stack - doesn’t matter, it is a proof of concept. Six weeks later the proof of concept is done. It is not a static, prototype that demonstrates linear page flows, it is fully featured and fully functional. It can be usability tested (but more likely you were doing that on wire frames alongside the build). What then? In two months you’ve taken your idea and turned it into something tangible.

Why not put it into the market for real. Whilst IT might not want this Ruby “thing” on their stack, that doesn’t mean it isn’t possible and can’t be done. Large organisations have a testing ground of consumers inside a secure environment - their staff. Use them to beta pilot the idea? Friendly customers are delighted to be part of product development - put it out to a small and selected group of customers, and have some smoke and mirrors processes to handle fulfilment. The objective is to prove the viability of the idea, get data to make informed decisions and make your collective mind up quickly. To fail fast or succeed cheaply.

The traditional pattern for the on-line banking “make a payment” GUI is:

• What you are about to do (text)
• Select “From account”
• Select / enter “To account” (Beneficary)
• Enter Amount
• (Optional) enter “when” (you want payment to be made
• Confirmation (“you are about to pay this amount from this account to that account. Are you sure?”)
• Post process confirmation (“You have paid this amount to that account from this account”)

So here is a question. Are those confirmation screens really necessary. What if you made your payment, hit the “OK, make the payment” button and it is done. An alert appears (like when you do something with google) that says what you have just done with an “undo” call to action (“I’ve made a mistake, I don’t actually want to make that payment afterall”). The assumption there is that the user knows what they are doing – we assume a happy path with the opportunity to go back rather than placing “confirmation” barriers to completion which are probably unread anyway. There will be considerations of when the payment is actually made; does it hit the clearing systems when the user hits the pay button (not that it ever does anyway). Does the undo option disapear after a period of time (i.e. five minutes), or when the user navigates away from the page the alert appears? But let’s leave the implementation to one side.

I like the idea of undo instead of confirmation. However, I have a hunch that it will not fly when we show it to customers, because people are so ingrained with the “confirmation” dialog. I’m waiting for the response “I’m not sure I like that” from customers who use the current website, because it different, unexpected and is wholly inconsistent with what they have today. But what they have to day is based upon legacy technology and the immaturity of the platform.

So a suggestion. Let people undo. Tell them what they’ve done after they’ve done it (positive feedback), with the opportunity (in the banking environment in a time boxed period) to rectify their errors or change their minds. Do away with confirmation dialogs. Everywhere. (Do you want to save this document? - instinctively I say “no”. It is only later that I realise my mistake…) Here’s to a web that places minimal barriers to task completion.

A while ago Jeff Veen wrote that he “[didn’t] care about accessibility”.

It is exhilarating working with ThoughtWorkers who have a similar approach. It is not unusual for them to state blankly when the client starts talking about DDA. “Arrrrr” they will say when the acronym is explained. Disability discrimination Act- make it accessible? It is what we do. If what we build is not accessible we have not written good code - we have failed. Accesibility is a distraction - it should be a by-product of good development practices. They’ll wax lyrical about progressive enhancement and well structured mark-up and not only will it be inherently accessible but will work on mobile devices or any devices and off they go on a roll….

A funny thing happened today. We’ve had up on the wall our personas - boards showing the key users of the site we are developing; their photos and mood imagary visually describing them. These were stuck on top of earlier, crude descriptions of the personas with their names the same but different photographs and less detail.  A seperate workshop was held in another room and the boards were taken down for it, leaving the earlier versions behind.

Suddenly our key user who we are calling Saffron had gone. Her photograph had changed. Her “type” was the same, but her personification was different…

I was kinda attatched to the old Saffron. Who is this imposter?

In a while the boards will be put back up again and my Saffron will return…

Now whilst I am a keen advocate of personas to bring a user type to life, clearly there is a danger of getting overly attached to that persona, and that feels like a smell.

Michael Klynstra writes enthusiastically about Meosphere. My first impression is that I’m not so sure. It may be a cool and compelling proposition but it is not obvious to the visitor what it is all about. Needing a large call to action “Click here to see how it works” should set the alarm bells ringing. The target audience (I assume) are typically time poor and have limited patience or attention span. Why should they invest time into learning how to use the site, let alone actually interacting with it? This is where Facebook is so good. Blindingly simple home page:

Facebook is a social utility that connects
you with the people around you.

Clearly expressing the site’s value proposition from the outset…

It’ll be interersting to see how Meosphere get on. Good luck to them, but I wonder if they could have made the home page slightly more compelling and inviting to an unitiated user… Having said that, once they’ve got a community and people are emailing links, is that so important after all? When I signed up to Facebook, it was on the basis of an invitation rather than a visit to the homepage. So maybe if Meosphere get critical mass of community then homepage design isn’t so important and indeed Michael’s words will come true; web 2.0 at its best.

(Oh, and I drove a 1967 Volkswagen Microbus at “highschool”).