(UX) DESIGN let’s get started

Francesco Marcellino Allianz Worldwide Partners

November 10, 2015

THIS IS NOT ✗  a talk on visual design

and UI/user interface... ✗  a wireframes or photoshop

comps production course... ✗  the ultimate UX approach,

or a rigid point of view

THIS IS ✔  some hi-level as well as practical

tips on how to design more usable and useful solutions - which solve a problem and answer actual needs

+what is UX?

user experience = all aspects of the end-user's interaction with the company, its services, and its products. (J.Nielsen, D.Norman)

a human being with a goal

a product

a pleasant interaction and feeling

UX

+how to deliver good UX?

How to deliver a good UX...

ü meeting the exact needs and goals of the customers

Ø  so we need to know them...

ü pleasing these people with simple and joyful interactions

Ø  so we need to deliver useful functionalities, but also take into account emotions & feelings...

ü meeting business goals, creating new value

Ø  so we need to decipher them...

Examples: •  save time •  save money •  look good •  feel good •  solve a problem

Examples: •  build loyalty •  reach a bigger audience •  inform, or entertain •  solve a problem •  fill a need

a product

WTF..reak!

+how do we start?

Answering 2 key questions, and only then thinking about solutions...

PEOPLE

PROBLEM SOLUTION

use

addresses

have

Then thinking on HOW to solve those problems for them.

2. WHAT problems do they have?

1. WHO are the users?

By thinking about the whole system...

Scheme credit: @katerutter

Users

Needs

Uses

Product

Features

Company purpose

+ your vision and ideas

Product

Users

Needs

Uses

Features

+knowing users and needs

the average person does not exist, so avoid designing for that

“ The average person has one testicle and one fallopian tube - (Bo Burnham)

Image credit: @FakeCrow

Instead, define a few

personas Personas are representations of a client’s customer. They are fictional characters that we create, which serve as a reminder of who our users are.

What to consider: name, age, occupation, status, location,

motivations, goals, frustrations, personality, skills, tech habits,

biography

and don´t forget to think also about your

stakeholders Sometimes who you are designing for is different than who pays the bills, and you need to consider their needs and goals as well.

+envisioning the key use cases

Image credits: @katerutter, and Visual Translations

use cases Once needs & goals are defined, we can act on those by identifying and ideating new value propositions. By using simple sketches, we can better describe the key uses cases. Photographs or videos work, too!

+making a feature list

features list Once we´ve defined users´needs and goals, as well as the key uses cases shaping the novel value proposition, we can finally think on the key limited features to support those uses.

A golden rule: keep things simple very simple!

+prototyping

prototype sketches, wireframes, physical mockups... it does not matter what you will use, and at which level of fidelity. Just use what’s best for you end enough for communicating to everyone on how your solution actually works.

+test and validate

(usability) testing test your ideas, prototypes or live product with real users, as soon as possible. Do not guide but observe them, so to understand what’s not clear. Then change, update, and test again!

Image credit: Mediamatic

+interaction design tips: usability heuristics

usability heuristics = are 10 general principles for interaction design, defined by Jakob Nielsen in 1990. They´re called "heuristics" because they are broad rules of thumb, and not specific usability guidelines.

1. Visibility of system status “I know what´s going on“

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

2. Match between system and the real world “I know what you´re talking about“

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.

3. User control and freedom “Oops, let me outta here“

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.

4. Consistency and standards “Seems familiar, makes sense“

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

5. Error prevention “Glad I didn´t do that!“

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.

6. Recognition rather than recall “I know what I need to do here“

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.

7. Flexibility and efficiency of use “Allow me to do more or less“

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.

8. Aesthetic and minimalist design “Looks good, works beautifully“

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.

9. Help users recognise, diagnose, and recover from errors “I know what went wrong, I can fix it“ Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

10. Help and documentation “Okay, I need help“

Even though it is better if the system can be used without documentation, it may be still necessary to provide help. 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.

Thanks Francesco

a bit