BTD quiz #2: Usability issues resulting from a staggered web application release

May 14, 12:14 PM

Here’s another little usability conundrum for all you user experience designers out there. This question was asked of me recently while designing an online transactional web application for a company here in Melbourne and I’d like to hear any suggestions you may have about how best to tackle this issue…

The client wanted to release their shiny new web app as soon as possible. The reasons for this from a business point of view were obvious, not least to get to market first ahead of the competition! In order to do this however, the plan meant releasing a basic version of the app with a limited feature-set first, with the intention of releasing updates over time, adding features within various sections of the application.

At the time of launch the full app architecture had been decided upon, with the final app to consist of a series of about 7 sections, each to contain a number of features. Some sections would contain all or some features available now, whereas others would not contain any until such time that they were developed and released later.

My question is this – Should the app be released with:

  1. The full architecture in place with all sections and labels visible to the user such that they can get a feel for what will be the full app, even though some sections will be empty at launch (These pages could be populated with content about the features that will redide here eventually).
  2. The full architecture in place with all sections and labels visible to the user, but ‘disabled’ or ‘greyed-out’ until such time that they become ‘active’ and contain content.
  3. Only sections with active feature content visible, with a view to ‘turning-on’ sections and their relevant labels/buttons as the content is added.

Personally I would say option 3. People will try and click links that are grayed out anyway so don’t confuse them. Only show what they can actually use.

Releasing the new functionality as ‘upgrades’ is also a good business trick for the company (even though they planned to do them all along).

Matt CareyMay 14, 07:18 PM

Hey there Matt!

That’s interesting – I was siding towards option 1 so that new users get a good idea of what will be available in the future, although I realise this could be considered a little frustrating (to go to a section and find nothing usable there).

Ben TolladyMay 15, 08:17 AM

I think it solely depends on three things:

1. what the feature is (i.e. how important is it to the user experience)
2. when you will deliver that feature
3. how you execute the idea

If the feature is unique in how the users will behave and interact with the entire application, then perhaps there should be a different strategy in how you show cast this features. Games do this really well by having really groovy videos. When HL2 announced its amazing physics engine, it did so by creating an amazing demo, which really highlighted how they stood out from the pack. If they had just made tons of claims, then no one would of bothered.

Some other examples:

Clearleft’s Silverback (http://www.silverbackapp.com/) had enormous success with this sort of marketing, however personally I think most of it was due to the company’s overall success and credibility.

Cloverfield played this game really well by constantly referring to the idea of the “unknown” and using lots of fancy camera tricks :)

On the other, if it is poorly executed and you get nothing more than an annoying “Under Construction” message or your mouse turns to a “Restricted” cursor, then it sort of feels like going grocery shopping for something that’s advertised as “50% off” and only to find they don’t actually sell it in that store.

Anyway that my two cents!

Anton BabushkinMay 26, 05:19 PM

Comments are closed for this article.