Complex User Interfaces Don't Need to Be...Complex

1,347 views

Published on

Some user interfaces (UIs) can be designed to be incredibly simple and easy to use, whereas other UIs need to incorporate and support some level of complexity, whether it be the agent's screen design for a call center or the user workflow for system admins on enterprise applications. All too often, UIs are painted with broad brush strokes in terms of simple vs. complex.

This webinar presentation addresses the following questions:
• Where does 'complexity' come from?
• What 'complexity' is unavoidable?
• What 'complexity' is avoidable, and how can you avoid it?

Published in: Technology, Design
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,347
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • This webinar is one of the many free webinars User Centric is providing as part of our We Believe Experiences Matter webinar series. Sign up and access to our previous webinars are available on our website. For those of you familiar with User Centric, you may notice that our tagline has changed from “If technology doesn’t work for users, it doesn’t work” to “We Believe Experiences Matter”. A key part to our belief that experiences matter is that all touch points are important
  • , and to that end, I wanted to give a quick shout out to my colleagues who burned the midnight oil last night as one of our last steps in beautifying our new downtown Chicago offices to amplify great experiences within our lab space. They had to paint 88 12x12” squares, each a different color, times three rooms that serves as our project ideation rooms. As you’ll note, the photo on the left is time stamped at 9:45p when they finally ordered dinner in, and at 11:45, they were nearly finished with cleanup. Thanks guys!
  • History of human factors got its start in aviation…
  • Other interfaces can be deemed complex, like this console for a train conductor
  • And likewise for the folks coordinating the trains from a command center
  • complexity can be seen on devices like precision tooling interfaces
  • And on software for producing music
  • And there are hosts of other software interfaces that could be described as complex…
  • In the examples I just showed, I would concede that some degree of complexity is required, yet, when we go back to stakeholder goals and objectives for the design of a product, complexity is seldom, if ever, a word they use
  • Want to divorce complexity from other words that are typically associated with the word but have emotive qualities, like complicated.
  • Easier example is when business make certain features or access to specific content purposely more complex in order to achieve certain business objectives. One example is the business objective or reducing call center volume. Some companies have made it difficult, if not impossible, to find their phone numbers… as an aside, our research on how this is implemented suggests there are ways to reduce call center volume without having to hide the phone number…
  • Complexity may simply be required to support user tasks; completing taxes is necessarily a complex activity, as would be flying a plane…
  • One interesting thing we’ve unconvered through research is that complexity can sometimes be fabricated from the user him/herself… for no intentionally malicious reason … On a previous design engagement, we were redesigning an automated ordering system that was developed to optimize the workload from store managers. When conducting our initial research on how the store managers were using the new automated ordering system, we observed that they actually went in and changed all the proposed order quantities; on top of that, several vocalized how they conducted mental math to determine whether to change the quantities that were being proposed by the automated system, and worse yet, they were making calculation errors! One might have concluded that even the automated system did not adequately address the complexity of the task at hand for these store managers, but our conclusions were actually that complexity in the task of ordering supplies was fabricated due to some sense that this task is one of their core contributions as a store manager, and an automated system that took this task away – more minimized the level of complexity – would possibly have an impact on the value of their position. Paired with TRUSTING the system ….
  • Another interesting finding from research we’ve conducted talks to a widely debated question of whether products should be designed for function or for aesthetics. We recently conducted co-design workshops with users of a website … . Their feedback called for an initial screen that provided search functionality, aggregated lists, and certain visual displays. . Upon viewing a proposed concept where none of these elements were represented, but rather was designed more minimalistically, the users unanimously preferred the more aesthetically pleasing design versus their originally proposed design that support many functions on one screen.
  • User research is not simply hearing what end-users say, but listening and gaining insights to why they’re saying what they’re saying. Additionally, as the function vs. aesthetics example illustrates, user feedback is often highly contextual and limited based on their own experiencesbut Hearing is simply the act of perceiving sound by the ear. If you are not hearing-impaired, hearing simply happens. Listening, however, is something you consciously choose to do. Listening requires concentration so that your brain processes meaning from words and sentences. Listening leads to learning.
  • If we are successful at divorcing complexity from the negative attributes like complicated, then there are certainly times when complexity is a good thing
  • Taking on one the key talking points from a previous User Centric webinar on heavily-used interfaces, complexity is particularly useful and often necessary for heavily used applications and for expert users. Some of the key strategies for designing complex interfaces include…
  • While there are certainly instances where complexity can be a good and necessary thing, there are perhaps more times when we are tasked with making the PERCEIVED complex … simple.
  • I want to talk through some key strategies for making complex interfaces not so complex. They include: …
  • Involves focusing on the most critical features, functions, and user tasks or workflows when designing an interface. The goal is never to provide full functionality with equal weight and prominence within an interface, but rather use the 80/20 rule to focus the interface on they key features or functions, and contain peripheral features and functions on secondary screens
  • One of the most popular ways to reduce interface complexity is the use of progressive disclosure …
  • Visual grouping essentially chunks a long list of items into consumable groups that would otherwise be inconsumable if presented as simply one list; visual grouping is certainly not limited to text but can be applied to page elements and functions
  • Another popular way to reduce interface complexity is through the use of contextual controls; not all features and functions need to be prominent at all times; in fact, it’s often the case that most features and functions are only relevant at key points within the user workflow. Some great uses of contextual controls include contextual help, which eliminates the need to present help text littered across a screen as well as bring users to a general help page from which they would have to navigate to get to the appropriate help topic. Contextual menus are widely used on both desktop and mobile applications, where options are only relevant on key screens or interactions
  • The use of icons can greatly reduce complexity by providing decluttering a page and optimizing scanability; the key is to use unabiguous and intuitive icons; all too often, users must rely on the icon labels (or worse, mouse overs)
  • Complex User Interfaces Don't Need to Be...Complex

    1. 1. PRESENTER: MODERATOR: #uxlunch© User Centric, Inc., July 2012 1
    2. 2. © User Centric, Inc., July 2012 2
    3. 3. Why Are We Here? Who We Are What We Do The Webinars Today’s Topic© User Centric, Inc., July 2012 3
    4. 4. Why Are We Here? Who We Are • • • What We Do • • • The Webinars • • • • • • Today’s Topic • • •© User Centric, Inc., July 2012 4
    5. 5. Why Are We Here? Who We Are • • What We Do • • • • • The Webinars • • • Today’s Topic • •© User Centric, Inc., July 2012 5
    6. 6. We Believe Experiences Matter TM 9:45 PM 11:45 PM© User Centric, Inc., July 2012 6
    7. 7. Why Are We Here? Who We Are What We Do • • • The Webinars • • Today’s Topic© User Centric, Inc., July 2012 7
    8. 8. Why Are We Here? Credit: UX2.0 Usability Test Report© User Centric, Inc., July 2012 8
    9. 9. © User Centric, Inc., July 2012 9
    10. 10. Complexity Defined© User Centric, Inc., July 2012 10
    11. 11. Complexity Defined© User Centric, Inc., July 2012 11
    12. 12. Complexity Defined© User Centric, Inc., July 2012 12
    13. 13. Complexity Defined© User Centric, Inc., July 2012 13
    14. 14. Complexity Defined© User Centric, Inc., July 2012 14
    15. 15. Complexity Defined© User Centric, Inc., July 2012 15
    16. 16. ‘Complexity’ is typically not a goal for design Credit: UX2.0 Usability Test Report© User Centric, Inc., July 2012 16
    17. 17. Complexity is wrought with emotional baggage© User Centric, Inc., July 2012 17
    18. 18. Complexity ≠ Complicated • • • • • •© User Centric, Inc., July 2012 18
    19. 19. Complexity ≠ Complicated© User Centric, Inc., July 2012 19
    20. 20. Complex User Interface, from a stakeholder’s POV • • • • • •© User Centric, Inc., July 2012 20
    21. 21. Complex User Interface, from a developer’s POV • • • • • • Ray Toal, Developing Complex User Interface Applications in Java© User Centric, Inc., July 2012 21
    22. 22. Complexity ≠ Complicated© User Centric, Inc., July 2012 22
    23. 23. © User Centric, Inc., July 2012 23
    24. 24. Where does complexity come from?© User Centric, Inc., July 2012 24
    25. 25. Complexity originating from technology© User Centric, Inc., July 2012 25
    26. 26. Complexity originating from the business© User Centric, Inc., July 2012 26
    27. 27. Complexity originating from user tasks© User Centric, Inc., July 2012 27
    28. 28. Determining whether complexity is real or fabricated© User Centric, Inc., July 2012 28
    29. 29. What do users think about function vs. aesthetics? Function Aesthetics© User Centric, Inc., July 2012 29
    30. 30. Lesson Learned: Hearing vs. listening to user feedback© User Centric, Inc., July 2012 30
    31. 31. Where does complexity come from?© User Centric, Inc., July 2012 31
    32. 32. Tesler’s Law Front-end User Interface Back-end development© User Centric, Inc., July 2012 32
    33. 33. © User Centric, Inc., July 2012 33
    34. 34. Heavily used applications and the expert user • • • • • • •© User Centric, Inc., July 2012 34
    35. 35. © User Centric, Inc., July 2012 35
    36. 36. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 36
    37. 37. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 37
    38. 38. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 38
    39. 39. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 39
    40. 40. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 40
    41. 41. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 41
    42. 42. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 42
    43. 43. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows (This is a BAD example of exception reporting!)© User Centric, Inc., July 2012 43
    44. 44. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 44
    45. 45. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Controls Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 45
    46. 46. Strategies for making the ‘complex’ simple Prioritization Progressive Disclosure Visual Grouping Contextual Actions Iconography Consistent Interactions Exception Reporting Map to Mental Models Support Workflows© User Centric, Inc., July 2012 46
    47. 47. © User Centric, Inc., July 2012 47
    48. 48. Gregory Nunn© User Centric, Inc., July 2012 48
    49. 49. Albert Einstein© User Centric, Inc., July 2012 49
    50. 50. PRESENTERS: #uxlunch© User Centric, Inc., July 2012 50

    ×