A Multidisciplinary Approach to Universal Design
•
2 likes•1,316 views
Presenting a framework for universal design of ICT, at CSUN Assistive Technology Conference, March 2017.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to A Multidisciplinary Approach to Universal Design
Similar to A Multidisciplinary Approach to Universal Design (20)
Recently uploaded
Recently uploaded (20)
A Multidisciplinary Approach to Universal Design
- 1. A MULTIDISCIPLINARY APPROACH TO UNIVERSAL DESIGN Stein Erik Skotkjerra & Anders Skifte CSUN, San Diego, March 2017 A practical example
- 2. WCAG COMPLIANCE IS NOT OUR GOAL!
- 3. Anders ”Goose” Skifte @skifte Stein Erik “Maverick” Skotkjerra @skotkjerra
- 9. HOW DID WE GET THERE?
- 10. 1. Multidisciplinary workshops 2. Focus on universal design throughout design and development 3. Expert evaluation 4. User testing 5. Reflection and learning STEP PROCESS TO UNIVERSAL DESIGN
- 11. MULTIDISCIPLINARY WORKSHOPS DESIGN AND DEVELOP EXPERT EVALUATION REFLECTION AND LEARNING USER TESTING UNIVERSAL DESIGN
- 12. Prerequisites…
- 13. Everyone involved in the project has to pull in the same direction
- 18. Focus on universal design throughout design and development 2
- 20. The Radar Team UX / Product manager Graphic design Front-end Front-end
- 24. Standards conforma nce User needs Tide crack © Chris Hill / Australian Antarctic Division
- 25. Adam Clarkson / CC BY-ND 2.0
- 26. By Norwegian Association of the Blind and Partly Sighted Technology For All
- 27. User testing4
- 28. Including people with disabilities in user testing can save you time and money
- 29. Adam Clarkson / CC BY-ND 2.0
- 32. We do not learn from experience… we learn from reflecting on experience – John Dewey
- 33. Learn from your mistakes by fixing your own bugs
- 34. styleguides.io
- 37. Nothing beats user testing with people with disabilities
- 38. Wrapping up…
- 39. 1. Multidisciplinary workshops 2. Focus on universal design throughout design and development 3. Expert evaluation 4. User testing 5. Reflection and learning STEP PROCESS TO UNIVERSAL DESIGN
- 40. There is more to universal design than being WCAG compliant
- 41. One does not have to provide a boring graphical user interface in order for something to be accessible and usable
Editor's Notes
- WCAG compliance is not our goal! And it shouldn’t be your goal either. WCAG is merely a means for reaching our goal, which of course should be world class User Experiences for all users - regardless of physical abilities, technology preferences, cultural background or knowledge about technology. If an excellent user experience is your end goal, then the best way to validate if you are reaching that goal, is by … testing the users’ experience, and whether or not they can actually accomplish what they came to accomplish.
- Lets quickly introduce ourselves.
- The example case we’re going to be talking about today, is the redesign and development of a web technology radar. On the screen you can see the 2015 version of it. The radar is a tool for showing trends in the Norwegian web tech world, and a new version of its contents is published once a year, reflecting the recent changes on the web technology scene. It’s shaped as a circle divided in four quadrants labelled Frontend & Mobile, Process & Quality, Architecture & Platform, Languages and Frameworks. It also has 3 rings for indicting how relevant each technology is. The outer ring is labelled «avoid», the middle one «trial», and the inner one «adopt». The dots in the radar represents different technologies. This older version of the radar suffered from severe accessibility problems
- It had insufficient keyboard support The radar points had no visible labels (before mouseover). .. and as you see here, the cursor is hovering over a point that resides under «adopt», in the Frontend and Mobile quadrant. The hover style makes it turn green, and a tooltip containing the word «React» becomes visible. The description for React shows up on the right hand side of the screen, pretty far away from the hovered point, and completely out of view for some users The radar was non-responsive It barely contained HTML-headings, And the list goes on…
- Then an awesome design team decided it was about time to scrap the old radar and to build something new. They initiated the process by doing a lot of research about how the old radar was used, what strengths and weaknesses it had, and what people actually wanted from it. They started sketching new ideas and concepts. They also developed low fidelity prototypes, and tested them on real users.
- The redesigned radar has more detail and lots of improvements. It’s showing only one quadrant at a time, but all four of them are laid out as navigation menu items in the top header section. If you’re interested, you can check it out at radar.bekk.no – Most of the technology buzzwords are the same in both languages anyway.
- When you click on a point, more information about that specific technology will open in a modal window, and when the modal is open, you can navigate through the radar points by using the arrow keys, and you can of course easily close the modal if you want to. So, altogether one could say that the radar is a complex, but still universally designed, tool for getting insight about web technology trends in Norway. It’s probably not perfect, as we believe is the case with most other systems as well, but the new and improved radar sure is a lot better than the older one. It’s easier to use, and it works well with assistive technology.
- All right, so what happened between the low fidelity sketches and the final product? How did we arrive at the new and improved radar? That’s what this talk is about.
- We have identified these 5 elements - or rather peaces to the puzzle - that are important for teams working on larger tech projects.
- The different elements are to be seen as iterative activities, and of course the process itself can be iterative as well. We’ll break it down for you and go through the elements, one by one. We will try to give you a general idea about the concept, and then show you how we implemented each element in the tech radar process.
- But first some prerequisites!
- Once you have set your goals and objectives regarding universal design, you need a strategy to accomplish them. This framework we present might be just what you need. In order for the team to successfully follow the process, everyone involved (in the project) has to pull in the same direction. Project managers, product managers and other stakeholders need to understand why universal design matters, and they should encourage the team to explore the field – and to make everything accessible.
- The first element is multidisciplinary workshops! They are a great tool for bringing the different roles in a project together to establish common goals and to solve complex problems. An example could be a workshop where designers, developers, accessibility experts and other stakeholders set goals, establish a common language for communicating and identifying potential challenges and solutions. If this is done at the start of development and design, it can eliminate problems before they arise, and all disciplines are enabled to put their expertise and perspective forward. Workshops can be iterative, and the activity should be repeated throughout the development phase.
- If the team doesn’t possess the required expertise on universal design, they should have access to someone who has that expertise, whenever necessary, and on a regular basis, and for the whole duration of the project. Having someone guiding the team in the right direction along the way will result in a much better solution than for instance just ordering an accessibility report in the final phase of the project, and maybe never having or taking the time to do anything about the findings. Working together like that saves a lot of time – and probably money too – compared to spending days and nights, typically just before launch, ripping it all apart and then glueing it back together, because of bad design decisions and too many accessibility bugs.
- Workshops like these, where expertise on universal design is available, can also be great for kickstarting your project. In our case, the before mentioned radar concept was brought into a workshop where the goal was to take the it further, and to start working on both interaction and graphic design. A mix of UX designers, graphic designers, front end developers and accessibility experts, all attended the workshop. Having such a mix of expertise available in an early stage, helped ensure that we ended up on the right track right away.
- The output of the workshop was refined navigation and interaction concepts, and several graphic design proposals. The second design sketch, sowing the contents of a single radar quadrant, and the article display page on the right, is actually pretty close to what we ended up with.
- The team as a whole needs to have some level of expertise in the field of universal design, but not everyone need to be an expert, as long as someone is wearing the a11y-hat, taking the responsibility for communicating accessibility to the team, sharing of their knowledge, and keeping the project on the right path by striving to make accessibility a part of everyones workflow. We believe that a great team environment is one that’s cross-functional and collaborative, so that all disciplines are working together on both design and functionality. This will result in better solutions, because each problem is seen from many different points of view. If the team doesn’t have the required expertise in accessibility, we strongly suggest that they bring in the experts every once in a while, so that the team’s assumptions can be validated as early as possible.
- The radar development team was made up by a UX-designer / product manager, a graphic designer, and two front end developers. They varied in experience regarding universal design, but they were strong on collaborating, and learned a lot from each other. They focused on universal design throughout the entire project, and everyone got to share their opinion on the design and how all the the features should be implemented. In addition to that, Anders was invited to join them as an accessibility expert for several a11y-workshops along the way.
- As mentioned before, it is not necessary that all members of a team has in depth knowledge of accessibility. However, everybody should have a minimum of knowledge on the aspects of universal design that has implications for their role. A good way to ensure that the solution you are developing has a certain level of accessibility is to perform an expert review. This can be done both on design sketches and a coded prototype. The main goal of an expert review is to detect basic flaws in design or code as early as possible.
- Expert evaluations can take different forms, but generally I divide dem into two main categories: continuous evaluation and assessments. Continuous evaluations are done throughout the development phase and the goal is to identify weaknesses and potential improvements to design, interaction, code etc. They should be performed by experts who has experience and knowledge about the principles of user experience, and in our case, specifically universal design. Before starting an expert review the team should do what they can to remove simple bugs and problems so that the expert reviewer can focus on the important things, and does not need to spend time commenting on simpler issues.
- Assessments are meant to assess a solution at a given point in time against a specific set of criteria. The typical WCAG review would fall into this category, and risking to offend some people among the listeners, I would say assessing WCAG compliance is for the QA department, and not the most effective way for designers and developers to get feedback on their work.
- Both practical experience and research tells us that adhering to guidelines is not necessarily enough to ensure usability. In fact, research shows that conforming to the WCAG guidelines will only uncover 35 to 50% of actual problems experienced by users with disabilities. Most researchers and practitioners will agree that user research and user centered design and development processes are effective.. We even know that there might be direct conflict between the requirements of the WCAG guidelines and recommendations based on usability testing. This sometimes leaves us with the dilemma of wether to prioritize conforming to guidelines and standards or cater to user needs we have found through user research.. We need to learn which types of testing methods work for what purpose. Some times testing with assistive technologies will give us the information we need, and sometimes user research is the best choice.
- If a developer gets an excel spreadsheet with WCAG violations listed and is asked to correct them, she would probably first of all be close to dying from boredom and frustration. Secondly, she will have to implement the changes, put a check mark in the column for «corrected», and return the excel sheet. What has she learnt from this experience? Maybe something about how to correct some specific problems, but she probably has not learnt a lot on what she should do differently next time she is coding something.
- Many of the bugs and problems that were found by the team, were both easily discoverable and fixable. Once they got cleared out of the way, the team went on with more in depth testing, and worked together with experts from The Norwegian Association of the Blind and Partially sighted. They performed a couple of expert reviews, while for the most part sitting in the same room as the team. Because of colocating everyone, the team got to discuss different accessibility concerns on a deep, technical level with the experts, and that led to new and valuable knowledge. And because of the team's efforts on continuously dealing with “low hanging fruits”, the experts could dig right into more complex issues. As a result, the overall code quality and user experience was improved even more.
- Through a study we ran last year we discovered that by user testing a solution on a group of people with disabilities compared to a group without known disabilities. The group including people with disabilities was half the size of the «other» group, we detected all the serious general usability problems, and got loads of accessibility specific feedback as well. This means that testing with people with disabilities is not only the right thing to do, but also can save you time and money. Another good thing about user testing in general is that it lets the team see their product in action, feel the pain or joy as users explore it, and to learn lots and lots about how it actually works.
- Let’s go back to our developer who was hit on the head with a list of WCAG violations. If she was allowed to observe users solving tasks, she will see for herself what problems they face, and she could use her specific expertise together with the rest of the team to develop the best solutions to the problems. Sometimes the solutions are not merely changing some code, but maybe it will affect design, and interaction as well. By bringing the entire team into the research cycle, it develops empathy for users and the problems they face. Usability testing should be a group activity. With the entire team watching the tests, absorbing the feedback, and reacting in real time, you’ll find the need for subsequent debriefings reduced. The team will learn first-hand where their efforts are succeeding and failing.
- Here is a picture from one of the user test sessions, where some of the team members and others are observing a blind person testing the radar. Being present during user testing like that and observing users struggle with using the web app, really served as an eye opener for the team.
- Very simply put reflection is about noticing an experience, evaluating what was good and not so good about this experience, and deciding on actions you could take or things you can change to do more of what was good and less of what was bad.
- To maximize learning, the one making a bug should also be the one responsible for fixing it. With some expert guidance, everyone will learn from their mistakes. As accessibility experts we have all too often ended up being the one fixing accessibility bugs in the final stages of a project, to save time, while others have moved on to other projects making those same mistakes again.
- As progress evolves, and you learn what works, you should consider documenting those patterns in a style guide. A style guide is something that typically contains both reusable and quality-assured elements and components, and having such a thing really helps ensuring universal design across teams and websites or apps. If you’re interested in learning more about style guides and what they can do for you, styleguides.io is a good place to start.
- If you need to increase peoples motivation for including people with disabilities in their daily work, we’d recommend empathy exercises such as simulating a disability. They do not teach you how it feels like to have a specific disability, but it may raise awareness about the challenges different people face. These gloves are really cool because they will literally shake your hands. They will get your hands to tremble. They can be used to simulate Parkinsons, or just being nervous or just really hung over, and they come with a control unit that lets you control both the intensity and frequency of the shaking. The gloves work by sending electric impulses through your body, so they should be OK to use for everyone not having a heart condition or anything like that. Here’s a video showing how they work. You can imagine this guy is having a hard time hitting smal touch areas on his phone.
- Another great simulation tool is the Cambridge Simulation Glasses! They simulate a general loss of the ability to see fine detail, and it’s quite similar to what happens when ageing. They’re thin and made of paper, and you can wear multiple pairs on top of each other. By looking at this poster poster showing lines of text running from high contrast to barely visible, while wearing two pairs of glasses, people tend to have severe difficulties reading low contrast text below line number 8. And that’s funny, because the contrast ratio here is 3 to 1, which is the minimum requirement for large text.
- As we’ve seen you can simulate different disabilities to raise awareness and build empathy, but nothing beats user testing with people with disabilities. It’s an eye opener – and for the radar team members, working with universal design went from being somewhat cumbersome and merely based on assumptions to actually being inspiring, interesting and fun.