Share 'Consider This Before Designing Your UI' on Facebook Share 'Consider This Before Designing Your UI' on Google+ Share 'Consider This Before Designing Your UI' on LinkedIn Share 'Consider This Before Designing Your UI' on Twitter

Consider This Before Designing Your UI

In my last blog, I discussed the history of user interface (UI) design technology, going back to my early days as a developer at the time windowed operating systems were gaining popularity. The technology has come a long way. Now with the use of scripted languages like Python, Ruby on Rails, or PHP – plus an increased understanding among developers on what makes for a good user experience – it’s possible to create intuitive and elegant interfaces. But first, developers must consider the frequency of user interaction with a product or service. 

Distilled down to the core, I believe one of the key considerations for UI design is frequency of interaction. Certain classes of products are used every day – email and cell phones are easy examples. Daily use means that users will eventually learn to manipulate even the most arcane UIs, but daily use soon becomes daily annoyance. Apple has built a very successful business solving the daily use problem in a way that people find intuitive, fun, and easy to use.

For product that require less frequent interaction, the user experience is different and therefore a different UI is warranted. An easy example here is the wireless router in my home – interaction is so infrequent that I often forget the admin password. The keys to a successful UI for such products are memorability and learnability. How much do I remember about how the UI works or how quickly can I relearn what I knew a long time ago and even then only used for an hour or so.

Some products span both use cases. For example, Axcient’s core data backup, business continuity, and disaster recovery services involve frequent interaction as our managed service provider (MSP) partners deploy new systems for new customers or expand services for existing customers. Intuitive ease of use is critical in this case.

The UI for other Axcient services such as Cloud Continuity aren’t used as frequently – perhaps one a month for testing, but subsequently used only following an actual infrastructure failure. In use during an emergency, the stress level is high and the need for successful operation is critical. Obviously, learnability and memorability are critical factors here.

I believe that the second use case, infrequent but mission critical, is the most difficult UI challenge. The team at Axcient spends a lot of time and effort here, cutting down on the number of active pages, optimizing the flow, and honing the graphics. There is no substitute for hundreds of iterations, and scripted languages make iterative processes much easier.

The final perspective I’ll share here is that once a development organization takes the first step toward a highly evolved user experience, there is no turning back. From that point forward, every new feature means that every flow, every screen, and every icon requires extensive scrutiny. For even moderately complex products, this very quickly leads to dedicated user experience (UX) resources and eventually a UX team.

While skilled UX engineers have historically been a bit of a scarce commodity, I’m sensing that this is about to change. Particularly at college career fairs, I’m finding interns and new grads with highly evolved perspectives on user experience. Whether this is the result of a new generation of engineers having grown up with iPads and iPhones or simply cognitive science majors eyeing a lucrative career as a UE designer, I really can’t say. Either way, highly evolved user experience is a trend that’s here to stay.

Leave a Reply

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

* Copy This Password *

* Type Or Paste Password Here *

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