Body off Baywatch, face off Crimewatch ... do customers prefer it to function, look good or both?
Fortunately in the blogosphere (eeugh) someone somewhere will be talking about a topic that's pertinent to your current interests. This week my regular read of Marc’s dancingmango site hit a nerve (in a good way) by talking about transactional regions (“Most retail banking web presence is just not connected”). At The Company my colleagues and I were recently debating whether transactional areas should look different from static ‘brochureware’. I think they should, or at least that it doesn't matter if they don't. In the olden days, Jakob used to say that web-based applications shouldn’t ape browser interraction. But this was before XHTML and JavaScript reached near universality and the vast majority of users expect a rich interface.
Marc’s spoken in the past about breaking free from linear form completion in a wonderful post (“Shoot the wizard! Designing a real world form”) and I support this idea of complete user control. Where I differ from him, and to return to the point, is that I believe customers appreciate a pared-down approach to look and feel on transactional sites. Yes there are legacy issues and, from our own back-end, I know these things tended to have been built by systems guys rather than web designers but the effect has been that there tends to be less distractive marketing guff (page bloat is another thing .. see below) and provided they’ve been interatively designed and user tested, things tend to work functionally.
I’ve mentioned in the past that I think the future will see us move to a more conversational web and increasingly customers will eschew sites that hark back to the days of padded table cells in favour of sites where the brand fits their expectations and aspirations - but we’re not there yet. We’re still, as consumers, focussed on speed and task efficiency and so sometimes keeping the box of crayons away from the menu board helps keep this focus. That said I am aware of situations where non-native web coders (and by that I mean teams where the day job is back-end code) have been left to develop the presentation layer and the result is bloated code, high page weight and long download times. Not to mention accessibility and cross-browser compatability issues.
In short, I don’t think we need to sweat it too much when transactional elements measurably work but don’t look great but I do think we need to worry when we separate static from transactional for cost and infrastructure reasons only to find that we’re suddenly using a top-nav where a left nav was before and the page loads would test the patience of a narcoleptic sloth. Marc cites some great examples where this disconnect has resulted in sloppy coding on transactional sites (HSBC image and First Direct image).
My final caveat is that this holds true for financial services sites and the more tedious transactional elements online. It’s pretty brand dependant; Lloyds TSB for example don’t need an exciting online banking service, they need one that’s quick, fully functional, compliant, compatible and secure. On the other hand if the Apple store was all this but visually dry and plain you’d start to feel a disconnect with the brand because, for someone like Apple, their consumer brand runs right through the entire customer lifecycle.
Marc’s spoken in the past about breaking free from linear form completion in a wonderful post (“Shoot the wizard! Designing a real world form”) and I support this idea of complete user control. Where I differ from him, and to return to the point, is that I believe customers appreciate a pared-down approach to look and feel on transactional sites. Yes there are legacy issues and, from our own back-end, I know these things tended to have been built by systems guys rather than web designers but the effect has been that there tends to be less distractive marketing guff (page bloat is another thing .. see below) and provided they’ve been interatively designed and user tested, things tend to work functionally.
I’ve mentioned in the past that I think the future will see us move to a more conversational web and increasingly customers will eschew sites that hark back to the days of padded table cells in favour of sites where the brand fits their expectations and aspirations - but we’re not there yet. We’re still, as consumers, focussed on speed and task efficiency and so sometimes keeping the box of crayons away from the menu board helps keep this focus. That said I am aware of situations where non-native web coders (and by that I mean teams where the day job is back-end code) have been left to develop the presentation layer and the result is bloated code, high page weight and long download times. Not to mention accessibility and cross-browser compatability issues.
In short, I don’t think we need to sweat it too much when transactional elements measurably work but don’t look great but I do think we need to worry when we separate static from transactional for cost and infrastructure reasons only to find that we’re suddenly using a top-nav where a left nav was before and the page loads would test the patience of a narcoleptic sloth. Marc cites some great examples where this disconnect has resulted in sloppy coding on transactional sites (HSBC image and First Direct image).
My final caveat is that this holds true for financial services sites and the more tedious transactional elements online. It’s pretty brand dependant; Lloyds TSB for example don’t need an exciting online banking service, they need one that’s quick, fully functional, compliant, compatible and secure. On the other hand if the Apple store was all this but visually dry and plain you’d start to feel a disconnect with the brand because, for someone like Apple, their consumer brand runs right through the entire customer lifecycle.
No comments:
Post a Comment