Selecting an appropriate UCD (User Centred Design) method is vital.
Human-Centred Design Process: ISO 13407
Its goal is to achieve usable systems.
It is a standard, a framework for applying HCD and evaluation techniques.
It supplements existing lifecycle modes by specifying general activities to be performed in development, but it doesn’t demand or recommend particular techniques or methods.
It defines one stage of UCD as the specification of user and organisational requirements.
This should:
- Identify the range of relevant users and other personnel in the design.
- Provide a clear statement of the HCD goals.
- Set appropriate priorities for the different requirements.
- Provide measurable criteria against which the emerging design can be tested.
- Be adequately documented.
The Star Life Cycle
It emphasises that ordering of activities is inappropriate.
It is evaluation centred and encourages iteration.
User Requirements
Determining user needs can be quite hard, because:
- User rarely knows what is possible.
- User may not know their needs, what they need to achieve their goals and interests.
Specifying a design is not just giving people what they ask for, again they don’t really know what they want.
It is important to define user requirements as they determine what we are trying to create in the design process, especially early on.
It also supports defining usability requirements:
- Useful in early design, but more critical at the evaluation stages.
- Asks: how do you asses if your design is or will be successful?
Why gather requirements?
They aren’t usually a “given” factor:
- They aren’t always what they initially appear to be, or what designers are told that they are.
- Stakeholders conflicts can arrive.
- Including within the design/development phase.
How to Identify Requirements
You need to identify:
- What
- The things they use to do the work.
- Who
- The people involved with the work.
- Where
- Where the work is done.
- When
- What time is the work done.
- How
- The processes that involved in the work.
- The information required to do the work.
- The constraints imposed on the work.
- The problems they face in the work.
- The inputs required by the work.
- The outputs created by the work.
- Why
- They do they do they work, and in this way.
Different Types of Requirements
Functional:
- What a system is supposed to do.
- Is it necessary? Is it useful?
Non-functional:
- How a system is supposed to be?
- Often called qualities of a system.
- Criteria that can be used to judge the operation of a system.
- Your usability requirements should describe the context of use:
- Who, what, when, where, and why.
User Requirements:
- Define how to meet users physical and cognitive needs.
- Who will be using it, in what environments (e.g. knowledge, roles, abilities).
Usability Requirements:
- Specifies a required amount of usability: a measurable quality, so an engineering target, for example around
- Efficiency: goals are easy/quick to accomplish, with few/no user errors.
- Intuitiveness: easy to learn and navigate, simple to understand.
- Low perceived workload: not intimidating, demanding or frustrating.
What is a “right” requirement?
- Just in time, just enough detail.
- Can take a long time to do, no more than is necessary.
- Realistic.
- Don’t expect too much.
- Clearly and unambiguously defined.
- Relevant
- Relevant to designers, relevant to the next cycle of the design process, helps solve a design problem/question.
Personas
They are documents that describe typical target users.
They are a critical method for orienting design and development teams to user experience.
A persona represents an aggregate of target users who share common behavioural characteristics, for example is a hypothetical archetype of real user.
Perona perspectives: goal, role, engaging, fiction.
More info here.
Why?
- Requirements.
- Visual design.
- Quality assurance.
Using Personas
- Expectation.
- Behaviour.
- Context.
- Feedback.
Issues with Personas
- They are abstract: hard to understand abstraction process from user data to persona, so personas come across as lacking critical detail.
- They are impersonal, the personifying details in personas fail to provide a sense of empathy.
- Details mislead, it is difficult to select personal details that do not create a false constraints on the design problem.
- Personifying details distract, they make it hard to focus on the aspects of a persona that are critical for the design problem.
Benefits of Persona
- User insight.
- Process of personification.
- Constant reminders.
- Personas vs Real People.
Minimum Persona
- Picture.
- Name.
- Age.
- Location.
- Occupation.
- Bio-rich story that adds reality.
Optional Content
- Educational level.
- Salary or range.
- Personal motto.
- Online activities.
- Offline activities.
- Trigger or touchpoint for service.
- Technical comfort level.
- Social comfort level.
- Mobile comfort level.
- Motivation to use service.
- User goals.
Guerilla Personas
Limited money, limited time: empathy map.
