INTERACTIVE AXIOM #4: Usability's Equivalent Exchange

INTERACTIVE AXIOM #4: Usability's Equivalent Exchange

THE EASIER YOU WISH TO MAKE IT FOR YOUR USER THE HARDER AND MORE EXPENSIVE IT WILL BE FOR YOU TO CREATE.

This is a natural law in Interactive development; an equivalent exchange.  And there is a point in the development of every project I have ever engaged in that this axiom hits the table.

It's ironic on some level that you, the developer and client, have to endure quite a lot of complexity, difficulty and cost - more than beginners initially expect -  to make the user's experience conversely simpler and more effortless.  But it's a fact.

That's because interactivity is not about a single path or way of doing things (though many clients walk in thinking it is).  It's about potentials and variables.  You are creating an environment where the User should have the freedom to move where he wishes.  This naturally imposes development of varied and redundant pathways and functions.  And the more options the User has, the more rigorous I.A. (information architecture) and U.I./U.X. (user interface/experience design) must become.

There are an infinite number of possible user behaviors - and the ideal interactive experience is going to adapt to each of these users uniquely.  But since such a thing is not possible, we must group users into psychographic buckets and design for these subsets of users in hopes that the rest of them will "figure it out".  And it is in this stage of development, when use-cases are being grouped, and project plans are being assembled, that this axiom is most relevant.

At least initially, interactive developers almost always overtly target "user friendliness"; I've never met a client or developer who doesn't pay lip service to this ideal.  In fact it is so much a basic part of interactive development that there isn't a participant in the development process, from client to end user, who hasn't heard the industry term "user-friendly".  But despite the terms ubiquity, actual follow-through on this ideal is often compromised when cost and timing are factored in.

This axiom dominoes into the 1st axiom all the time.  This is when, at the start of a project, there are big claims about how "easy we want this function to be" for the user, only to choke at the numbers when the cost and schedule are realized.  More often than not, in an effort to reduce development difficulty and cost, smart use-case solutions are cut.

For example, users of shopping sites fall into some well-known groups (and some not so well-known) that shop differently.  Some users know what they want, others browse (in numerous preferred ways), others still like to customize, and so on.  Building a system that will allow each of these customers to self-select and follow their preferred path effortlessly often results in multiple ways of accessing the same information.  And as I say, this is where the bean counting takes a toll.  Faced with building what seems to be costly redundancy, many clients and developers will rather shoehorn some of those users into a single path - rather than incur the cost of true "user friendliness".

Look, I'm not totally idealistic, projects have to be profitable - so tough decisions have to be made.

This axiom is more about avoiding the shock of it.  It's about setting expectations - with yourself, your CFO, or your client.  Just don't be surprised, when you've stressed user-friendliness (and you should!), that your experienced agency shows you a budget that is higher, and a schedule that is longer, than you'd hoped.It really does take longer and cost more.