User Interface Design - Concepts, Objectives and Thoughts

• discoverability—Can users quickly find the model’s primary object and understand how to perform the actions they care about? Can they use the system successfully the first time?
• learnability—How long does it take for users to internalize how to use the system competently? Even consumer products often have a slight learning curve today. For example, my company just gave me a new smartphone, and it took me a bit of exploration to understand how to use all of its cool features—not to mention how to avoid draining the battery in three hours.
• user efficiency and productivity—Once users are competent using the system, how easy is it for them to perform common or repetitive tasks? Can they perform bulk actions all at once, or do they have to perform dozens or even hundreds of separate actions?
• system response time—Once users take an action, how long does the system take to respond? In a production environment, user efficiency and system response time combine to define the total task time. Designers have a responsibility to understand the expectations and constraints on system response time and design a product that meets or exceeds those expectations.
• delight—How cool does the product feel to users? Do users like using it? How much do they like it—especially in comparison to other products? I set up a Customer Listening organization, and we’ll be systemically gathering this type of data—along with Net Promoter Score data—to drive the top five to seven product improvements each quarter.

Why ditch wireframes?

So what’s so wrong with wireframes? Well wireframes themselves are not necessarily bad; it’s more the sort of design behaviour they encourage and the way they are often used (and abused) in projects. Here are some reasons why for the vast majority of projects wireframes should be consigned to the rubbish bin.

• Wireframes (which are static by nature) are not well suited to defining dynamic on-page interactions, such as expanding content, AJAX style reveals and animations. As the boundaries between web and desktop applications become increasingly blurred and on-page interactions become more common place wireframes simply no longer cut the mustard.
• Wireframes are not very user friendly (which is kind of ironic for a UX design tool). Project stakeholders are often intimidated by what they perceive to be very technical documentation and find it difficult to understand exactly what wireframes are, and what they show.
• Wireframes are typically very open to interpretation. Wireframes look like they’re very exacting and specific but because behaviours and interactions have to be described they are by nature very open to interpretation. One project stakeholder can read a wireframe very differently from another which can lead to confusion and misinterpretation.
• Wireframes can encourage the ‘lob it over the fence’ approach to design. Designers can spend ages meticulously creating, annotating and updating wireframes and then lob them over the fence for the development team to build; safe in the knowledge that everything is documented, so any dialogue can be avoided.
• Wireframes can be too prescriptive. Many visual designers can feel that wireframes reduce their role to little more than a colouring in exercise; one of applying the necessary branding and look and feel for each screen rather than carrying out proper design work.
• Wireframes often add unnecessary drag to the design process and can encourage death by documentation (a particularly nasty way to go). Creating and annotating detailed wireframes takes considerable time and effort; time and effort that is usually better spent iterating and improving designs, rather than specifying them.

• Prototypes are a much better at communicating a design. It’s much easier to sit down with designers, developers, product owners and of course users to get feedback and to run through design ideas if everyone can see how things might work with their own eyes.
• Prototypes are more user friendly. Where as people are often scared off by wireframes everyone understands what a prototype is (just make it clear that prototypes are very different from the finished article).
• Prototypes require less documentation as they are less open to interpretation and on-page interactions can be mocked up. If you do need to document your prototypes (hopefully with an emphasis on ‘just enough’ documentation) then you’ll find yourself having to write many fewer comments for a prototype than a set of wireframes.
• Prototypes better support user-centred design. It’s much easier to carry out usability testing with a prototype than a set of wireframes and to get lots of juicy feedback from users in general.
• Prototypes require less work. If you are careful to prototype ‘just enough’ to get the feedback that you need then prototypes typically require less work than wireframes because you’ll need to write (and maintain) less documentation.

Grab as many different coloured post-it notes as you can

You'll be using post-it notes to capture user steps, questions, ideas and comments so you’ll ideally want 4 sets of different coloured post-it notes so that you can assign a unique colour to each. If you can get your hands on some super sticky post-it notes (yes, such these do exist) then all the better because regular post-it notes can sometimes struggle to stick vertically to walls or paper.

Grab a roll of brown packing paper and some blu tack

Unlike the post-it notes these aren’t strictly necessary, but are handy for being able to transport your scenario maps when you’re done. By sticking long strips of the brown packing paper up on the wall and sticking the post-it notes to these you can easily take your maps away with you when you’re done.