It’s the simple things that confuse

We’ve been working on an interaction problem that highlights the way people digest a page and how easy it is to render interactive elements magically invisible.

There’s two key factors attributing to the magic invisible element; the visual design focuses people on the core page functions; and the functionality is secondary and completely unexpected. If the problem was purely visual we could provide a visual solution, however as people do not expect this particular functionality, they’re simply not looking for it. We’ve tested this behaviour in sessions with users by steadily increasing the visual weight of the element – to a ridiculous level – and people aren’t taking the bait.

We can’t show examples as the interface is still in the production, however, the point of this post is to illustrate my own personal experience with magically invisible elements. The site in question is called NeonMob and it’s all about collecting and trading digital artworks. I absolutely love the idea (here’s my collection so far) and have heard it described as Pokemon for designers.

The problem I had arose when I needed to sign-in to the site. Here’s the sign-in page…

Showing typical human behaviour I dove straight in – without reading one word on the page – and entered my email address and a password. Attempting this process several times, without success and receiving this feedback each time…

Really nice error feedback mechanism; it draws attention and I did read the message it contained – invalid signin credentials, yo – in fact it was the only text on the page I spent time reading. Oops!

Eventually I read the field labels and realised my error was in looking at the page through a lens based upon my experience of conventional sign-ins. The two adjacent fields were for email and username – if I’d remembered the sign-up process I might have expected the sign-in process. Of course, I didn’t remember the sign-up process; it’s very similar and I think I may have attempted to enter a password in the username field in that instance. Hmmm.

There was a single cue – apart from the labelling of fields (which I clearly didn’t read) – that hinted at the correct content for the field. It felt entirely unnatural, but I could read my password username as I entered it; the system even displayed an autocomplete menu to help me remember my password username. D’oh!

Honestly, I did not expect a sign-in process that excluded the need for a password; the requirement for entering the username was therefore completely invisible to me and my expectations for a sign-in process. In fact an easy fix for this simple interaction problem on NeonMob would be to remove one of the fields.

So, the point of my tale is while we can provide beautiful designs with all the appropriate visual cues and hierarchy, if the person viewing the page doesn’t expect to find certain functionality, then they won’t be looking for (or expecting) that functionality. In this particular instance I almost gave up – only returning because I really like the site (and I’m stubborn).

Meanwhile, the client project continues and we’re about to revise and re-imagine the magically invisible elements based on user testing feedback. It’s important to note the key reason we were able to expose such behaviour was because we user tested the interaction and visual design with a realistic high fidelity prototype.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">