UCD / IxD Introduction - User centric design, interaction design
•
0 likes•544 views
This document provides an introduction to user-centric design (UCD) and interaction design (IxD) principles for building software. It discusses how UCD tools like personas, goals, and interaction loops can help design coherent experiences and increase agility, sanity and quality. While earlier software was system-centric, the focus is now on designing intuitive experiences through iterative collaboration using UCD and pairing it with Agile development methods.
Report
Share
UCD / IxD Introduction - User centric design, interaction design
- 1. UCD introduction A basic intro to user-centric design, as it relates to building software.
- 2. great software at high speed (the goal)
- 3. play book Successful teams know what plays they’re running, why, and how. The principles of UCD (and IxD) help you setup plays.
- 4. topics
- 6. source:
- 7. source: alan cooper Godfather in Silicon Valley. OG.
- 8. indelible Alan Cooper’s ideas have left an indelible mark on how software design’s approached.
- 9. dancing bear Imagine one end of a town square, where a man bring’s in a bear, dressed in a tutu and clown hat, and gets the bear to dance. People’s attention is captivated that is even possible. At the other end of the square as a world class dancer pirouettes and piqué’s, few notice. As time passes, the novelty of the dancing bear wear’s off, and the absence of technique and refinement becomes obvious. The human dancer stands out with consistency, emotion, technique. We must beware of “dancing bear” technology products that distract with novelty, but have little long- term value.
- 10. Example products, bleeding edge, don’t produce quality output, but stood out because, “holy shit this works!”.
- 13. context In earlier eras of software development, applications were “system centric”. The CPU, memory, and graphics abilities were limited and therefore defined what could be done. The physical size of a punchcard determined how much information could be carried. These limitations have evaporated, increasing flexibility, but requiring more design guidance to produce coherent products.
- 14. software quality What the computer could do used to define what software did.
- 15. software quality over time Over time, technical capability has improved, and so has collective knowledge about building effective & intuitive applications.
- 16. daily use Daily use software is especially demanding of an over-arching approach to maintain coherence, and intuitive experiences.
- 17. improvement? How many have observed improvements in software in the past 10-20 years? Clearly, the proliferation of effective, intuitive software has increased.
- 18. dog’s breakfast? Still, we see applications that are mash-up of too much noise and incoherent navigation.
- 19. tolerance for bad design impatience / friction Gmail, iPhone, Amazon, TurboTax, Pinterest have raised the bar. As builders, we must elevate our craft. Tolerance for friction and incoherence has diminished.
- 20. our context What’s expected of software builders?
- 21. an engineer should: code test do the interface prototype manage scope spec document communicate be fast pontificate know everything Many, many things are expected (concurrently).
- 23. TOO MUCH not fun Over time, this results in reduced problem solving capability, job satisfaction, and output quality.
- 24. TOO MUCH inefficient Poor use of resources.
- 25. TOO MUCH incomplete Key parts of build and support get missed.
- 26. – scramble – – too much – – don’t support – – crap –
- 27. – scramble – – too much – – don’t support – – crap – ( repeat ) Engineering organizations get stuck in loops.
- 28. It becomes a continuous scramble to maintain systems.
- 29. break the cycle
- 30. shake shit up
- 31. get out of our comfort zone This requires revisiting the same thing 3, 4, 5 times. Being brutally honest. Keeping egos in check. Nurturing the best ideas.
- 32. what’s UCD? What is UCD and can it help ameliorate these issues, and increase quality?
- 33. 3 powerful tools
- 35. personas
- 36. personas (not actual people) If you build based on actual person, given enough time, then that person will inevitably dictate features that are specific to them. Examples; applications become entirely mouse-driven, keyboard centric, or focused on granular data to the extent that they bury the key insights they’re supposed to surface.
- 37. goals
- 38. tasks aren’t goals A task is to secure-copy modified image slices to the server. A goal is to quickly replace content with an audit trail.
- 39. specificity Goals need to be interrogated, refined, polished; not taken at face value in one discussion. Missed test cases, incompatible features, and unanticipated risks come from a lack of specificity.
- 40. personal Goals can be divided into 4 types. All types need to be considered. Example personal goals; 1. Don’t feel stupid while using application. 2. Commensurate effort: Help user feel like amount of effort makes sense for desired outcome.
- 41. professional Examples: Launch quicker enough to capture market-share, beat competition.
- 42. practical Accomplish the nuts and bolts. Example; accurately record orders. Create numerical model of business.
- 43. false Some goals bleed into the realm of being a “false goal”. Example: Reducing processor use is a false goal if it’s invisible to users, and not anticipated to become visible (as more people use the application). These are means to an end, not ends in themselves.
- 44. clarity of purpose If clarity of purpose is lacking, the underlying goals need more attention.
- 45. IxD Personas lead to goals. Goals lead to…an interaction with a piece of software. As a result, the discipline is called Interaction Design > IxD.
- 46. how we experience software Interactions reflect how we experience software.
- 47. how we experience software loops With each sitting, we go thru a loop.
- 48. IxD Designing and optimizing coherent loops is the focus of IxD.
- 49. user centric What does it mean to be user “centric”.
- 50. not user driven Not to be confused with user “driven”.
- 51. not user driven Many software teams find themselves stuck in patterns that look something like this. End-users are given override authority to put anything into an application.
- 52. not user driven This shift is subtle at first, but takes over, and then drives the entire endeavor.
- 53. not user driven not user interface elements This leads to very granular interface and business element determination by end-users.
- 54. not user driven not user features timing This results in an unmanaged flow of features, and expectations about time requirements.
- 55. not user driven not user features timing FML! Maintaining a coherent experience, reliable code, clean data becomes impossible.
- 56. riding the tiger This is called…riding the tiger.
- 57. diner that runs the kitchen Another analogy…
- 58. where can we take this? How can this be put in place?
- 59. what do we have? Take stock
- 60. what do we have? personas goals
- 61. ask the right questions Don’t assume we ask the right questions in the 1st, 2nd pass.
- 62. build quickly, without making silly mistakes Let the method guide us, not ride us.
- 63. can’t be done by one By definition, is a collaborative endeavor.
- 64. can’t be done by one person skill set group layer This will fail if key pieces don’t get skin in the game.
- 65. define our environment We know how many products, but how many domains do we have? How many applications? How many platforms should this turn into?
- 67. get out of our comfort zone We’re used to working in the business, so working on the business will feel uncomfortable at first.
- 68. evolve how we do things
- 69. designing an entire experience from sit-down to stand-up Our overall goal is to design the ongoing software experiences that we require.
- 70. best in breed examples: Amazon check-out Gmail read/reply Pinterest browse JIRA list sorting There’s good info out there! Don’t reinvent the wheel.
- 72. good artists copy great artists steal
- 73. repeat:
- 74. user centric
- 75. personas > goals > interactions
- 79. designed, not incidental software Good software doesn’t come out of nowhere, or happen by accident.
- 80. If Interaction Design (IxD) represents the yin of our ideation, then what about the yang, our production method?? How can we complete the picture?
- 81. Agile Agile is the other half of this story. The method we can use to turn the designs into reality. ! We can talk about that…
- 82. ...next time
- 83. –ernest hemmingway “write drunk, edit sober.” Parting words of wisdom…
- 84. q&a