Posted by
A collaborative medium, a place where we all meet and read and write.
– Tim Berners-Lee
[[Part 3 of 7 : 0) intro, 1) story, 2) pictures, 3) users, 4) content, 5) structure, 6) social media, 7) evaluation]
In the 1970s, the waterfall model was enthusiastically embraced by software engineers to enable them to get a handle on designing big software systems, although its proposer Winston Royce had issues with his model and discussed how it could be improved in the very first paper (IEEE, August 1970). He even included some agile-like programming ideas.
The main problem with the waterfall model was that the testing phase was the first time users saw their proposed new system. This meant that once users had experienced it, they wanted to change the requirements to better reflect what they needed. This would either result in a redesign of delays and rising costs, or users being lumbered with a system that did not reflect their needs.
Technology may have moved on immeasurably since the ’70s, but human communication skills have remained pretty much the same and identifying requirements is as huge a challenge today as it was back in Royce’s time. This is because what users think they want, is often very different from what they actually need.
To try and manage this gap, there have been all sorts of waterfall model modifications and alternatives: iterative waterfall, exploratory programming, rapid prototyping, and agile programming to name but a few.
Each approach has tried to be more flexible and iterative in order to accommodate users and produce better usable systems. In 2001, the agile manifesto was declared, promising to deliver software regularly to meet the changing requirements of all the people involved who would work together to produce something good.
And, nowadays, a usability specification is included in the requirements phase of the software lifecycle under ISO, International Standards. This demonstrates the recognised need for a more user-centred design practice, which hopefully leads to focusing on how users want to use a system rather than forcing them to change their behaviour and adapt their working practice to a given system.
Designer Donald Norman invented the term user experience to: cover all aspects of the person’s experience with the system including industrial design graphics, the interface, the physical interaction and the manual.
Norman felt that the term usability, the assessment of how easy an interface is to use, was too narrow, and wanted to reflect how a user experienced the system rather than just defining usability goals as part of a user requirements specification.
However, usability and users are just one, albeit important, part of the equation. There are business managers and stakeholders and a whole host of socio-organisational issues in the culture of each business, which can make the design process a complex one, which is why good designers shouldn’t just solve the problem that is asked of them, as Norman says:
It’s almost always the wrong problem. Almost always when somebody comes to you with a problem, they’re really telling you the symptoms and the first and the most difficult part of design is to figure out what is really needed to get to the root of the issue and solve the correct problem.
– Interview at adaptivepath, (2010)
Each business has its own way, or culture, when designing software. Some companies employ user experience and interaction design consultants (the lovely pic below describes the distinction) – individuals or companies – and some businesses just leave it to their programmers or web designers who might either work on the front or back end, or both, depending on the size and complexity of the system needed, and funds available.
There is no exact science to design and often the boundaries are blurred between roles. The main goal is to solve the right problem and support your user. And so we must begin with research.
Qualitative and quantitative research
Most projects are dictated by time and money constraints. However, even if you only have access to five users in total, it is still better to talk to them rather than designing something without any user consultation. Designers can never anticipate how users will interpret and use their designs.
Quantitative research, such as giving users a questionnaire or capturing their clicks as they perform a specific task on a website, is a useful approach if you want to collect results which are statistically significant, which you can present to stakeholders.
However, even if you use a more qualitative approach such as one-to-one interviews, full of open-ended questions resulting in many different answers, be assured, patterns will emerge in order to guide you. They always do.
If time is short, a quick way to gain insight into your users’ minds is by using one of my favourite approaches: the cultural probe. You give users a way to describe their tasks and thoughts and opinions whilst going about their business. This can take the form of a diary or an online blog, video, flickr account, whatever you think you might want to see and analyse.
The resulting data can be a most powerful way of demonstrating how users behave and work almost as well as having your user give an opinion in the lab, the other side of a two-way mirror, whilst your client/stakeholder is watching.
Human nature is endlessly fascinating and we have an inherent empathy with one another and storytelling underlies all communication. Thus, it makes sense that when we present all our facts, figures and qualitative patterns to the stakeholder, we shape them into easy to understand formats which echo our natural storytelling talents. We may want to use some or all of the following:
User personas
Personas were informally developed by the father of Visual Basic Alan Cooper in the 1980s as a way to understand the mindset of the users who would use the software he was designing.
They are a way of representing a particular audience segment, and generally have a group name: i.e., web manager. Added to this is responsibilities, age and education, and their goals, tasks and environment. Pictures and quotes help, as they capture more easily, a person’s motivations, frustrations and the essence of who they are.
Once the personas are in place, we can hear some of their stories:
User Stories
User stories, are mainly used in agile programming environments and they shift the focus from the system design: Hey, this is a cool feature, to the actual user and what the user wants to be able to do with the proposed system whether a given feature is cool or not.
As an Industrial Facilities Manager, Cathy is responsible for maintaining production systems and sustainability, which includes keeping equipment functional. She needs quick access to maintenance information and parts supply for her facility’s entire inventory.”
Example of a user story from www.newfangled.com
As newfangled.com says a story’s details are collaboratively worked on over time by everyone involved so that the story becomes a promise and a way to hold a conversation with users.
In agile environments, stories are the smallest building blocks which can be all joined together to make sprints, epics, and versions.
In a user experience environment, instead user stories are extended to make scenarios and journeys:
User scenarios and user journeys
A user scenario expands upon your user stories by including more details about how a system might be interpreted, experienced, and used by each persona group. Scenarios describe a user’s goal, specify any assumed knowledge, and outline details of the user’s interaction experience.
User scenarios are also referred to as user journeys in order to reflect the series of steps users go through either with the current service or website, or the steps they could go through with a different service or website, in order to achieve their goals.
User journeys/scenarios along with personas help to demonstrate to stakeholders how users behave and what their expectations are. Journeys also help visualise and articulate the key tasks and possible taxonomies that a system will or should include.
Chris Mears has created a very nice user journey’s tutorial in the UX review and a case study of user journey maps case study by Paul Kahn and Christophe Tallec has some lovely visuals.
Journeys can feed into use cases for software design, or the information architecture for website design.
Use cases and user flows
A use case expands on scenarios and creates a long list of steps, sometimes in a call and response approach between user and system, which a user might take in trying to get something done. It starts with how the user got there and steps through each user/system state until they have successfully achieved their goal or given up.
The focus of use cases is what a system needs to allow a user to do and so, use cases are used to define product features and requirements. The result is use case diagrams or user flows and some descriptive text, which illustrate and describe the sequence of user interactions.
This all feeds into the user requirements, so that finally, we have a rich understanding of who the users are, what the users need, the tasks they perform, and how they go about it.
Delivering deliverables
We have come a long way since the days of the waterfall model and system-based design. However, I still hear stories of users being asked to fill in a spreadsheet field or two with their requirements so the programming team can write an epic. Or, I hear that users can’t request requirements and code changes because: That’s just how the code works. Argh!
User personas etc., as tangible as they are, are only methods. They are not the deliverables of a project. Their only purpose is to facilitate user understanding. And we may have repeat them over and over until everyone is happy.
Used correctly, these methods can give everyone a good experience including stakeholders and designers. How brilliant is that?
10 comments