Posts

Showing posts from November, 2016

Prototyping

Sometimes prototyping can seem like a big investment of time, but I find it is always worth it. In this article on User Experience Prototyping , Paul Boag, who has been in the field of user experience for over a decade, writes about the benefits of prototyping. When most people think of prototyping they are thinking about mocking up a user interface. There is no doubt that prototyping can help in this area. Organisations use prototyping to define and test experiences using all kinds of interfaces. Interfaces from mobile apps to enterprise systems. He identifies three key benefits of prototypes: they are inspiring , and allow people to understand what is being proposed, because they show stakeholders what it will look like; they ensure a common vision - it is much easier to agree to something and come away with a shared understanding of it if you have actually seen what it will look like; they are testable - you can actually do usability testing with them and fix any usability issues b

Agile and Scrum

Agile development is an iterative and flexible process. Rather than specifying all the requirements of a project up-front and adhering to them throughout the development process (as happens in waterfall development), the requirements are listed as items in a product backlog. Specifiying software in this flexible and responsive way is better for customers and better for users. The product backlog is prioritised by the ' product owner ' (a role that represents the business users of the product to be developed). They can change the priority of an item in the backlog at any time. Each item in the product backlog represents a block of work to be done, which should ultimately result in ' shippable product ', otherwise known as a feature that users can use. Items in the product backlog are called 'user stories', which can be an epic (an overarching dewcription of some functionality), a spike (a time-boxed investigation), a bug (broken functionality that needs fixing),

Personas

A persona describes one category of the target users of your system as a fictitious but realistic person with goals and needs. It is useful because it summarises the user, their role, their skills and aptitudes, their preferences, and their goals. Personas give rise to user stories, and keep the user stories focused on the goals of real users. The persona needs to include a name and a picture, so that developers, business analysts, and testers can relate to it as if it was a real person.  It should include the following details: their demographic characteristics (e.g. age, disability) that might affect their interaction with the product, and their requirements in using it their role in using the software (e.g.  admin, editor, contributor, supervisor) what their job title is activities they do in their spare time which might affect their performance (either beneficially or adversely) their goals in using the software common tasks they will want to carry out using the software What probl

Hallway usability testing

Many people complain that usability testing is expensive and time-consuming. However, there is a very quick and very cheap approach to usability testing that any developer can adopt. It's called 'hallway usability testing' because you grab someone from the corridor and ask them to test your software feature that you've just developed. Obviously, as you have literally grabbed a passing colleague, you probably don't want to take up a huge amount of their time, so you only want to ask them one or two quick questions, such as "what do you think this icon means?" or, "can you find x piece of information?" The disadvantage of this approach is that the people you grab may well be other developers, and they may be so used to using lots of different kinds of software that they are not very representative of a 'naive user'. So hallway usability testing should really only be a precursor to real usability testing with a proper representative sample o

Behaviour-driven development

Image
Behaviour-driven development (BDD) has emerged from the practice of test-driven development (TDD). Whereas TDD focused on making sure that code worked and caught exceptions gracefully, BDD focuses on making sure that the functionality delivers business value and satisfaction to users. A typical BDD process might look like this: In behaviour-driven development: User behaviour drives development The team elicits user stories An analyst creates feature files The feature file becomes the test harness for development The team develops and tests against feature files The key features of BDD are: we write behaviour & specification that then drives our software development.  features are based on actual user behaviour & scenarios & user stories. the tests can be written by business analysts and stakeholders. The advantages of this approach are: Developers deliver what the users actually want It is rigorously tested The test shows that the feature meets the requirements (as opposed

How to write a user story

User stories are part of the Agile process. Agile development is iterative and broken down into sprints. Each sprint delivers “shippable product” – something that can actually be used by users, and which has business value. A user story looks like this: “as a [role], I want to do [task], so that I can achieve [goal]”. A non-technical reader who knows nothing about the system should be able to read your user story and understand it.The user story should not describe the technical details of how the goal will be realised; this should be left to the developers. The aim of a user story is to describe how the system will deliver business value to the end users. There are different types of user stories for different situations. You should write "epics" at an early stage, when you are working out the concepts behind the system, and the overarching problems you want to solve. Later, break your epics down down into more manageable user stories (features) at the point when you are nea

Writing style

An easy-to-read prose style is the first thing you need to get people to read your posts. Here are a few pointers: Say what you mean Use an appropriate tone Call a spade a spade – don’t say ‘utilise’ when you mean ‘use’ Vary your sentence length – too many short sentences is ‘choppy’; too many long sentences is boring. Avoid passive voice, e.g. ‘the business was lost by the inability of the sales team to convince the buyer of the uniqueness of their product’ (replace with ‘the sales team lost the business because they couldn’t convince the buyer that their product was unique’) Avoid clichés and stock phrases, e.g. France bit off more than it could chew in Vietnam , and America’s intervention was too little, too late . Avoid too many qualifiers, e.g. Most people usually think that many puppies are generally pretty cute. Avoid too many prepositional phrases, e.g. “the organisational culture of [your organisation]” could be replaced with “the way [your organisation] is organised”. Avoid t

Designing for emotional response

Design can elicit many different emotions. Many designers aim for surprise and delight, but those are not the only emotions you might want to elicit. If you are designing a site or an app for a charity or a campaign group, you might want to elicit compassion and a willingness to act - whether that is volunteering or donating. You might even want to elicit anger. Ages ago, the BBC published a series on user experience, and one of the things they talked about was BERTs - Bipolar Emotional Response Tests - which had a chart with a series of contrasted emotions (happy versus sad, angry versus calm, and so on) where testers were asked to respond to a design by marking on the chart how it made them feel. Their responses were then averaged out to provide an emotional profile of the website. A wheel of emotions This interview with Sherine Kazam offers a wheel of emotions and how they relate to each other (identified by Robert Plutchik in 1980). It's a more nuanced model, though I am not

Big Data

"Big data is a term for data sets that are so large or complex that traditional data processing applications are inadequate to deal with them. Challenges include analysis , capture, data curation , search, sharing , storage , transfer , visualization , querying , updating and information privacy . The term 'big data' often refers simply to the use of predictive analytics , user behavior analytics , or certain other advanced data analytics methods that extract value from data, and seldom to a particular size of data set." — Wikipedia This article, Inside American Express' Big Data Journey , explores what is needed to make the shift to using big data effectively. You need to be prepared for a journey . The changes needed won't happen overnight. You need buy-in from the top of your organisation. Without that, you won't get the mandate for the investment and the culture shift that is required. At the moment, big data technologies are still being developed,

Search engines and the 'filter bubble' effect

Image
There has been a lot of discussion over the last few days about social media filter bubbles and even search engines tailoring your search results to the kind of things you have previously clicked on, and therefore never showing you articles about the opposite point of view. Particularly this excellent article by Helen Beetham, Ed Tech and the Circus of Unreason : If we want to live in a liberal democracy, it’s not enough that some of us are media literate, or have an understanding of how statistics work, or can use our shared resources of historical, political and economic thought to think critically about the modern world. It’s not enough that some of us feel a stake in the future of our society and its institutions. Above all, it’s not enough that some of us have been exposed to the opinions and experiences of people very different to ourselves – in a supportive, developmental, educational setting that helps us to deal with the challenges of difference and emerge with deeper underst

Plain English

A succinct and simple writing style can make communication much more effective. Here are some tips for writing in Plain English. Read it aloud Tip: read through what you have written, preferably aloud. If it is difficult to read aloud, it will be difficult for users to understand. Jargon and acronyms Try to expand acronyms and explain unfamiliar jargon the first time you use them. Explaining procedures If you are explaining a procedure, try to set it out in small steps in the same order as the person will need to carry out the procedure. Plain English Avoid passive voice , excessive formality and using unfamiliar terms without any explanation. Passive voice example Plain English "Books may be borrowed from the library" "You can borrow books from the library" "It is recommended that..."  "We recommend that..."  it is preferred that a booked appointment is made  we would prefer you to make an appointment  Exc