Better ways to login

Excellent post at Cooper Journal discussing Better ways to login.

The article goes into great detail discussing the pros and cons of issues such as what to use for a username and password retrieval. Then gives case studies of the solutions used by many leading internet sites. Then gives recommendations for the ultimate login system. To quote:

Some users genuinely prefer to use a username, others prefer email. The system should allow users to create a username or use an email address as their login ID.

Allow users to add as many email addresses as they like to their account. It gives them flexibility in communications and verification.

I like the flexibility this suggests, but I have always been a big fan of email address – it just seems the simplest solution to me (and you know I like simple!).

I remember conducting numerous usability tests on ISPs back in the day. At the time each service (Freeserve, BT, etc) required the user to create a unique username. This simple requirement often created quite a significant barrier to users continuing the registration process:

• People would get very passionate about wanting a meaningful username and would spend a long time thinking about what it should be.
• People would get frustrated when the username they wanted wasn’t available.
• People wouldn’t know techniques for how to make a simple change to their preferred username to make it something unique.
• If people can’t use their preferred username, i.e. the one they use for every other system, then they are likely to forget the username and rely upon the forgetten password process.

The article offers good food for thought and I’ll certainly consider it in more detail the next time I have to give recommendations on a login process.

Iterative design alone can’t save us!

This was the subject of my slightly controversial presentation of this year’s OZ-IA conference. My talk wasn’t against iterative design, but definitely in favour of early stage contextual research to fully understand the user landscape in which you’re creating a solution for.

I am sure I’ll blog around many of the topics from the presentation in the coming weeks, but in the meantime my slides can be found at http://www.slideshare.net/iain.barker/context-is-everything-from-ozia-2008-presentation.

There is also a streaming video of the presentation. The visual quality isn’t the greatest (I’m the dot on the stage). But the mixture of slideshare and the video will make it like you were there yourself!

Video can be found at http://www.ustream.tv/channel/oz-ia2008 – you’ll have to dig around a bit, I can’t give a direct URL, but I’m far the right of the second row of videos.

Avoid formal specifications

Leisa Reichelt’s post On documentation (or lack thereof) rang a lot of bells for me. Until my most recent engagement, it had been many years since I’d produced a specification collating together a range of information architecture deliverables into a single formal project deliverable that was then handed over to developers for implementation.

Like Leisa, I would categorise the documentation I have produced over the last 5 or so years as “just enough” followed up with lots of collaboration. By this I mean the antithesis of thorough documentation of every aspect of an interface. Instead I would produce a series of interim materials that are enough to get other members of a project team all working towards a shared goal, and support that through face-to-face communication. (By this I mean exemplar wireframes, templates, interface rules, etc).

I think this non-formal specification approach is more in the spirit of user-centred design as it demands collaboration and facilitates iteration without the requirement to continually go back and update the documentation (surely a bugbear of more than just this IA).

To summarise, I prefer a documentation light approach because:

• It encourages and enables you to keep on iterating far later in the project.
• It makes more parties (i.e. developers) creatively engaged in the project.
• It ensures that the designers (i.e. IAs) maintain involvement in the project while it is being coded.
• It removes the temptation of focussing on your deliverable rather than the user experience of the final product. You will not be able to point at the spec and say “they didn’t implement it right”.
• It requires communication and collaboration.
• It is the antithesis of the waterfall development approach!

I am not saying no documentation, but all too often documentation is something we hide behind. Try existing with less documentation and you will have a far more collaborative project.

Information scents rule!

I spoke at the OZ-IA conference yesterday and added my thoughts to the Long Pages Rule! and associated discussions (such as Millisa Tarquini’s article Blasting the Myth of the Fold at Boxes and Arrows).

It is information scent not long pages that rule. If you set off with the objective of designing a page so that it is long, you’re heading in the wrong direction. In my presentation I cited the example of Norway’s tabloid newspaper Vg. The homepage of Vg clocks in at a staggering 10,500 pixels. If you set off with the objective of creating a long page (because long pages rule) then Vg is what you could end up with.

Instead of focussing on length per se, I prefer to focus on the information needs of users. What is required on this page so that users can confidently step closer to the information they require?

Increased page length is often a by-product of creating stronger information scents, but it should never be an objective in itself.

The quantitative and qualitative research, and anecdotal evidence provided by Milissa Tarquini, Jared Spool, ClickTale, EyeTrack III and others all point to the fact that scrolling is becoming less of an issue for users. Lets take this as an opportunity to design better navigation pages with stronger information scents rather than longer pages simply with more ungrouped content and imagery.

My previous article about information scent can be found at http://www.steptwo.com.au/papers/kmc_informationscent/index.html.

My article got published on Boxes and Arrows

An article I wrote about 12 months ago finally got published on Boxes and Arrows today.

The article is an extension to Donna Maurer’s card-based classification evaluation technique, it is called “Measuring the Success of a Classification System” I wrote it while working at Step Two Designs. It is quite an involved piece strictly for IA’s only. Hopefully more inspirational articles will follow, but a nice practical one to get me started.