I remain fascinated by everything that’s happening in the wearable technology space. I wrote about this space earlier, looking at companies such as Jawbone and Airstrip. With the annual Consumer Electronics Show (‘CES’) just behind us, I thought it would be good to look at some wearable trends to keep an eye on in 2014:
- Gaming – The Oculus Rift is the first product that comes to mind when I think about wearable innovations in the gaming space. Rumoured to launch in Summer this year, the Oculus Rift is a virtual reality headset which can be used for 3D gaming. This headset is all about ‘immersive technology’, which means that users can interact with games, being able to move your head in whichever way you’d like – just like in normal life (see Fig. 1 below).
- Fitness – Products such as Fitbit and Nike’s Fuelband are already quite mainstream. One doesn’t have to be a clairvoyant to predict that this trend of using wearable technology to measure fitness levels and daily activity is going to continue in 2014. Smartwatches such as Pebble (see Fig. 2 below) are definitely going to reinforce this trend.
- Audio & Photo – It might sound a bit spooky – and I’m unsure of some of the legal consequences involved – but soon we could all be recording audio or taking pictures without other people even being aware. Small wearable devices such as Kapture and Narrative (see Fig. 3 below) help users to record audio or take pictures respectively on the go. Most of these devices already integrate fully with smartphones so that for example all the pictures that you take whilst you’re running are automatically organised or stored on your phone.
Main learning point: Wearable technology will no doubt continue to develop further in 2014. It will be interesting to see how the various wearable devices out there will integrate with each other (think the “internet of things”) and what new use cases will materialise (think areas such as healthcare, time management and finance).
Fig. 1 – Testing the Oculus Rift developer kit (taken from: http://www.youtube.com/user/testedcom)
Fig. 2 – Review of the Pebble Smartwatch by Engadget (taken from: http://www.youtube.com/user/engadget)
Fig. 3 – Narrative Clip promo clip (taken from: http://vimeo.com/getnarrative)
Related links for further learning:
“Impact Mapping” is only 73 pages long but quality definitely rules over quantity in the case of this book by software delivery consultant Gojko Adzic. Too often we run the risk of diving into a software project or a product backlog without taking a step back to wonder “WHY?” or “HOW?”. If this sounds even remotely familiar to you, I would strongly recommend you have a read through “Impact Mapping”.
Impact Mapping is all about collaborative strategic planning around software projects. The book provides an abundance of practical tools to help you map your product roadmap or project plan, thinking about the business goals you’re looking to achieve and the specific assumptions that you’re looking to test. You thus create a clear mapping between goals and deliverables which helps at all levels, whether you’re planning a project, making a business case or need to choose between priorities.
In “Impact Mapping” Gojko Adzic makes a convincing case for how impact maps can help solve common problems around software implementation (see Fig. 1 below) and it does so by outlining 4 straightforward elements:
- Why? – The centre of an Impact Map should answer the most important question: “Why are we doing this?” This is all about the business goal or vision which a company is trying to achieve. Gojko stresses that goals shouldn’t be about solutions or the scope of the product that you’re looking to build. Instead, the goal should be the problem that you’re looking to solve (see also my earlier blog post about design thinking and creating problem statements).
- Who? – This level of the Impact Map is all about the actors whose behaviour you’d like to impact. Who are your target audience? What kind of value are they looking to gain from your product? In the book Gojko distinguishes between primary and secondary actors. Primary actors tend to be those whose goals are fulfilled and secondary actors are those who provide services.
- How? – The next level of the Impact Map combines the business goal (‘Why?’) with the actors (‘Who?’). The main questions here are: “How should our actors’ behaviour change?” and “How can they help us achieve our goal(s)?”
- What? – The ‘What?’ is about the deliverables or outcomes which can support the required impacts (‘How?’). These deliverables should be treated as independent chunks with each having tangible business value. When you do an Impact Map, you don’t necessarily have to describe the deliverables in great detail. Gojko explains that these deliverables can be treated as options and that only the high-level deliverables need to be listed in the Impact Map.
The result of these steps will be an Impact Map, a sample of which I’ve included in Fig. 2 below. Throughout the book I came across a lot more useful nuggets of information, some of which I’ll list here:
- Defining quality – In the section on “defining quality” Gojko makes an interesting point about the changed purpose of testing: “The role of testing becomes to prove that deliverables support desired actor behaviours, instead of comparing software features to technical expectations.” In other words, the focus of acceptance testing is much more about testing that the desired impact has been achieved.
- Roadmap management – I’m constantly learning about how to best think about and use product (portfolio) roadmaps. Too often I see long ‘shopping lists’ of features with a pre-determined scope – more often than not these roadmaps will evolve and so will the features on it. It was therefore interesting to read about the two prerequisites for Impact Maps to be used for roadmap management: (1) agreement that your aim is to achieve business goals, not to deliver pre-set scope and (2) frequent, iterative releases to measure progress.
- Iterative, not incremental – It might seem like a more semantic point but Gojko points out that a common way teams fail with iterative delivery is to incrementally deliver pieces that only bring value when they come together at the end. However, the main purpose of iterative delivery is to provide value (and shippable software) on a continuous basis (you might want to have a look at a great blog post that Jeff Patton wrote on this topic). Impact Maps can help top break deliverables down into branches that contribute to individual impacts.
- Divergent and convergent design thinking – Within Design Thinking there are roughly 2 phases: a “divergent” phase where teams will generate options to explore and a “convergent” phase where teams will decide which options are worth pursuing further. You can use Impact Maps at each stage, for instance to capture insights from product discovery activities (divergent) or to test the assumptions behind product ideas (convergent).
- Typical mapping mistakes – Finally, I found it helpful that Gojko illustrated some typical mistakes when it comes to impact mapping. For example, there is the “jumper” who tends to jump over levels in the map, the “astronaut” who just maps goals (and fails to include good metrics) and the “shopper” who goes into much detail too early on.
Main learning point: “Impact Mapping” is a very succinct and handy guide to planning and managing projects or product roadmaps. The iterative approach which the book advocates can be easily applied to a range of products and projects. This goal-oriented and data driven approaches forces people to think more about the “WHY” and “HOW” which is something that sometimes tends to get missed out on when planning projects or making product decisions.
Fig. 1 – Common software implementation problems which impact mapping can resolve (from “Impact Mapping” by Gojko Adzic, p. 20 – 21)
- Scope creep – Because there’s a clear mapping from deliverables to goals, we can measure when the main objective is reached and stop working on it.
- Wrong solutions – Because an impact map puts software deliverables in the context of business goals, it’s trivially easy to spot solutions looking for a problem, or those that would contribute to a different business objective.
- Pet features – Impact Maps allow us to quickly spot suggested features that don’t support any of the desired features, or do not contribute to the overall goal.
- Wrong assumptions – Impact Maps clearly show assumptions that we can track and validate them.
- Ad-hoc prioritisation – Impact Maps put features in the context of behaviour impacts, allowing stakeholders to relate better to benefits they would get from features and make much better prioritisation decisions.
Fig. 2 – Sample Impact Map (taken from: http://www.simplicityitself.com/training/impactmapping)
Related links for further learning:
In my last post I wrote about the use of heuristics to find usability problems in designs. In this post, I’ll look into the individual heuristic principles in more detail. It was UX expert Jakob Nielsen who introduced these “10 Heuristics for User Interface Design” in 1985 and these principles serve as a great context to evaluate user interface (‘UI’) designs against:
- Visibility of system status – “The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.” As a user, one always wants to know what’s happening; “what’s the status of my current action?” or “what’s happening next?” A good example is the file upload process on Basecamp where the upload button is enabled until clicked. It’s then replaced with a progress bar until the upload has completed (see Fig. 1 below).
- Match between system and the real world – “The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.” A good example is Apple’s iTunes library navigation where the terms used – music, movies, podcasts, etc. – are self-explanatory and unambiguous (see Fig. 2 below).
- User control and freedom – “Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.” An older example of how not to do this comes from “Amazon’s ‘Review and Sell Your Product'” form (see Fig. 3 below). The form doesn’t contain any (obvious) way for the user to cancel or revisit his listing, as observed really well by Lisa Duddington in her great blog post.
- Consistency and standards – “Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.” In your UI design you ideally want to create as little opportunity for user confusion as possible and consistency is therefore paramount. A good example is Microsoft Office where Word, Excel, and PowerPoint all use the same style toolbar with the same primary menu options: Home, Insert, Page Layout, etc. (see Fig. 4 below).
- Error prevention – “Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.” A good case in point is the “share” functionality in Yammer where the disable button is disabled after it has been clicked in order to prevent the user from updating the same post twice (see Fig. 5 below).
- Recognition rather than recall – “Minimise the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.” This heuristic is all about making information visual and directly available to the user. Try to avoid creating extra hurdles for the user and help user recognition with previews (e.g. offering previews of all available templates – see Fig. 6 below).
- Flexibility and efficiency of use – “Accelerators – unseen by the novice user – may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.” Examples of this principle are flexible shortcuts in the Firefox browser or having flexible defaults with options. A good example of the latter is Expedia who provide some set categories as part of its online hotel search functionality whilst still allowing users to enter a free text field.
- Aesthetic and minimalist design – “Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.” An obvious but great example in this respect is Google’s main search page, which is clear, functional and has loads of white space (see Fig. 7 below).
- Help users recognise, diagnose, and recover from errors – “Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.” This principle is all about making the problem (and the related solution) clear to the user, by for example highlighting the specific fields that the user forgot to fill out. It clearly helps if an application can show a path forward to the user. A good example is this page taken from a money management tool which explains in clear terms to the user which fields still need completing. I’ve included a similar error alert in Fig. 8 below and which proposes a way for the user to solve the problem.
- Help and documentation – “Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.” Examples of a good application of this heuristic are to help learning and decision making through the use of examples within the UI.
Main learning point: I found it incredibly helpful to delve a bit deeper into some of Jakob Nielsen’s “10 Usability Heuristics for User Interface Design” as it helped me to understand the kinds of factors which can influence ‘good design’. These principles can act as a great starting point when reviewing designs and user interfaces.
Fig. 1 – Screenshot of Basecamp’s upload process (taken from: http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5)
Fig. 2 – Screenshot of iTunes’ library navigation (taken from: http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5)
Fig. 3 – Screenshot of previous Amazon’s ‘Review and Sell Product’ form (taken from: http://usabilitygal.com/2010/04/30/amazon-fails-on-heuristic-%E2%80%98user-control-and-freedom%E2%80%99/)
Fig. 4 – Screenshot of Microsoft Office toolbars (taken from: http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5)
Fig. 5 – Screenshot of Yammer’s update feature (taken from: http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5)
Fig. 6 – Screenshot of the font options available in Keynote (taken from: http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5)
Fig. 7 – Screenshot of Google’s main search page
Fig. 8 – Screenshot of a message alerting the user that his USB device has not been recognised