Successfully reported this slideshow.
Your SlideShare is downloading. ×

Webinar UI/UX by Francesco Marcellino

Loading in …3

Check these out next

1 of 38 Ad

More Related Content

Slideshows for you (20)


Similar to Webinar UI/UX by Francesco Marcellino (20)

More from BeMyApp (20)


Recently uploaded (20)

Webinar UI/UX by Francesco Marcellino

  1. 1. (UX) DESIGN let’s get started Francesco Marcellino Allianz Worldwide Partners November 10, 2015
  2. 2. 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
  3. 3. 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
  4. 4. + what is UX?
  5. 5. user experience = all aspects of the end-user's interaction with the company, its services, and its products. (J.Nielsen, D.Norman)
  6. 6. a human being with a goal a product a pleasant interaction and feeling UX
  7. 7. + how to deliver good UX?
  8. 8. 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
  9. 9. a product WTF..reak!
  10. 10. + how do we start?
  11. 11. 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?
  12. 12. 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
  13. 13. + knowing users and needs
  14. 14. the average person does not exist, so avoid designing for that
  15. 15. “The average person has one testicle and one fallopian tube - (Bo Burnham)
  16. 16. 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
  17. 17. 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.
  18. 18. + envisioning the key use cases
  19. 19. 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!
  20. 20. + making a feature list
  21. 21. 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!
  22. 22. + prototyping
  23. 23. 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.
  24. 24. + test and validate
  25. 25. (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
  26. 26. + interaction design tips: usability heuristics
  27. 27. 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.
  28. 28. 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.
  29. 29. 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.
  30. 30. 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.
  31. 31. 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.
  32. 32. 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.
  33. 33. 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.
  34. 34. 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.
  35. 35. 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.
  36. 36. 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.
  37. 37. 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.
  38. 38. Thanks Francesco a bit