Breaking silos - all bad things must come to an end
•Download as PPTX, PDF•
5 likes•2,955 views
This document discusses how organizational silos negatively impact accessibility and provides recommendations for breaking down silos. It identifies common silos along discipline lines like development, design, QA, etc. and explains how each silo's isolated work harms accessibility. The document then recommends establishing governance, a collaborative culture, integrated standards and processes, training, and continuous improvement to break down silos. It provides action items each group can take to improve accessibility through cross-functional collaboration.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Breaking silos - all bad things must come to an end
Similar to Breaking silos - all bad things must come to an end (20)
Recently uploaded
Recently uploaded (20)
Breaking silos - all bad things must come to an end
- 1. Breaking silos All bad things must come to an end Henny Swan and Ian Pouncey The Paciello Group CSUN 2016
- 3. “a system, process, department, etc. that operates in isolation from others”
- 4. Defining Silos by Discipline • Developers • UX/Designers • QA • Product Managers • Business Managers
- 6. Discipline Silos • Developers • UX/Designers • QA • Product Managers • Business Managers • Accessibility Specialist • Accessibility Consultant
- 7. How does being siloed affect accessibility?
- 8. Developers • How does being siloed affect accessibility? • Only visual designs provided • 3rd party dependencies • Insufficient training • Accessibility is considered a technical challenge
- 9. User Experience and Design How does being siloed affect accessibility? • Development challenges not identified • Inconsistent design decisions between products • User experience research not shared • Teams isolated from the end results
- 10. QA How does being siloed affect accessibility? • UX not shared with QA • Accessibility standards not mandated • 3rd party dependencies • Test techniques not shared • Lack of understanding of severity • Lack of training in using assistive technologies
- 11. Product Managers How does being siloed affect accessibility? • Not aware of design or development challenges • Accessibility challenges not shared • Accessibility standards not mandated • Customer feedback not shared
- 12. Business Managers How does being siloed affect accessibility? • Inefficient feedback loops • Unclear governance structure • Procurement of inaccessible software • Signing off on ideas before being tested for feasibility
- 13. Accessibility Specialists How does being siloed affect accessibility? • Becomes the person responsible for accessibility • Lack of influence • Lack of support
- 14. Accessibility Consultants How does being siloed affect accessibility? • Focus on remediation • Focus on a product rather than process • Lack of organisational understanding • Lack of transfer of skills
- 15. Where are the silos in your organisation?
- 16. Part 2: Process
- 17. Integrated Accessibility • Governance • Culture • Standards • Documentation • Training • Continuous improvement
- 18. How does integrated accessibility fix the silos?
- 19. Governance How do we address the silos? • Establish a company wide sponsor • Define responsibility • Resourcing
- 20. Culture How do we address the silos? • Culture must come from the top • Encourage communication and collaboration • Empowerment to challenge decisions • Empowerment to take the necessary time
- 21. Standards How do we address the silos? • Beyond WCAG • Beyond compliance • Adapted • Integrated into process
- 22. Documentation How do we address the silos? • Documentation should be living • Appropriate format • Integrated • Accessible design patterns / libraries • Visual design language • Text alternative libraries • Manual and automated tests • User research repository • Annotated UX
- 23. Training How do we address the silos? • Training program not a one off workshop • Convenient • Provides a reference, allows for refreshing knowledge • All new starters receive training • Encouraged beyond basic training • Role based training available to all
- 24. Continuous improvement How do we address the silos? • Usability studies - regular and revisited • Share metrics, statistics, customer feedback • Keep documentation and training up to date
- 25. Part 3: Action plan
- 26. What can you do next?
- 27. Developers Discuss the next design you receive with it’s designer; indicate where you think there may be problems, or where there is missing documentation or information.
- 28. User Experience and Design Collaborate with developers when designing and document the accessibility features and requirements of your next design
- 29. QA Ask what accessibility / user experience tests are required for the next product you are testing.
- 30. Product Managers Make sure your team has the right training and resources; let company management know what you need.
- 31. Business Managers Formalise accessibility into practice - put together a plan, assign tasks and set objectives.
- 32. Accessibility Specialists Get accessibility written in to your objectives or job description so that you are empowered to spend time on accessibility and share your knowledge.
- 33. Accessibility Consultants Spend time to understand the organisation you work with and don’t be afraid to recommend they don't do an audit but do something else.
- 34. What are you going to do?
- 35. Thank you @iheni and @IanPouncey
Editor's Notes
- Started to think of silos in terms of disciplines because it’s what we’ve experienced The above also happens to be a common order of assumed responsibility (or blame) Also , mirrors how accessibility has evolved (used to be a developer issue, designers became aware later (as design evolved from print to web/app)
- In the context of this presentation we define specialist and consultant as follows: Specialist - embedded in design / development / management Consultant - outsider, often brought in at the end or for remediation rather than planning
- We considered two sides of silos: How it affects you How it affects the process
- Too often visual designs are thrown over the wall to developers without enough accessibility information Accessibility is a user design issue so needs to be led by design in the form of interaction design that includes keyboard and AT users For example, lacking focus styles or basic information on keyboard interaction It’s rare for a modern website or app to be built from scratch without 3rd party dependencies, which can come from inside or outside of the organisation. It may not be possible to make a site made from mandated dependencies accessible It’s unfair to expect developers who have had no exposure to accessibility to make the right decisions, but this is often the case. Accessibility had to compete with 101 other requirements. Lastly, it has been, and sadly often still is, common for developers to be the people responsibility, regardless of the decisions made outside of their control, for example, inaccessible designs or inaccessible components
- Designers lacking awareness of when implementations are not technically possible or, are technically possible but a terrible user experience e.g. custom components rather than standard components such as the dial on the BBC Radio app, anything to do with hover. Not sharing design decisions leads to inconsistency (an underlying principle of accessible UX), not possible for dev teams to be consistent if design teams are inconsistent. Reports are not added to a central knowledge base, findings are not shared in a bitesize easy to digest manner. Designs are handed over with no accessibility annotation, design is more than just visual design. Once a design team has worked on a site, app, or feature they are often moved on to new projects and do not see the final results for many months and may not be aware of them going live. Similar to the dev issue but more severe. May not even be aware that the design didn’t work.
- You can’t easily test for accessibility (or any other user experience aspects) without knowing what the UX should be, for example testing that focus is set to the right element when a button is activated. No collaboration between design and QA. In theory annotated UX > User Stories > Acceptance Tests, in practice its User Stories > Acceptance Tests Often, no accessibility standard (such as WCAG 2.0 AA) is specified as a requirement, so it doesn’t get prioritised for testing (testing is a risk / reward process - only test what is required to be tested) As with developers, the use to third party dependencies can cause a problem. They can produce false positives, or raise issues that are beyond the ability of the product to fix Testing needs to be done in a consistent manner to lead to the same result, and this should apply across all of a company’s sites and applications. Writing tests to prevent regressions after fixing bugs is also common, and that is an opportunity to test other sites to make sure they don’t suffer from the same problem that is often missed. Minor issues can be flagged as critical, and critical issues as minor and then ignored. If you don’t fully understand why you are testing for something it is difficult to understand the effect a problem will have on a user, and to then prioritise it accordingly. QA can’t test with AT such as screen readers if they don’t know how to use them
- Directly responsible for a product (such as a site or app) Often when designers or developers face challenges there is an attitude of fixing things themselves rather than communicate the potential problems. This may seem like a good thing to some product managers, but it hides problems and means that the right decisions can’t be made, or the right resources in terms of training, testing, etc. don’t get allocated. Sometimes products can exist in isolation, with not much communication between them. This leads to different solutions for the same problems, wasted resources, fails to show where effort needs to be concentrated to solve big problems because you never find out a problem applies to more than one problem areas Unless a business mandates a certain level of accessibility quality, for example meeting WCAG 2.0 AA, product managers have no way to measure how their product performs. Similarly a product manager must communicate their expectations to their team. Finally, in large organsiations it is surprisingly easy for product managers to be isolated from customer feedback. Without feedback a product manager is missing a valuable way of identifying problems and therefore make improvements.
- Business Manager does not directly manage a product, but might have product managers reporting to them, or may involved in business matters rather than product creation, but whose decisions still have an influence over products. Business managers are often unaware of accessibility requirements or the state of accessibility within a company. If they aren’t getting feedback from product teams they can’t make decisions around training or resourcing. Without management setting clear expectations there is no requirement or mandate for product managers to ensure that their teams have appropriate training or meet a particular standard of accessibility. Business Managers can’t assume that everyone knows the right thing to do, or that they are doing it. Governance - is not provided by the BMs so no knows what their responsibility or who does what. Business managers need to ensure that the procurement process for the entire business includes accessibility. Without this, anything that depends on inaccessible third party products or services will also be inaccessible. A sign off process that is top down and doesn’t include designers and developers will often lead to ideas that cannot be designed or implemented in an inaccessible way. Sometimes dependencies such as advertising campaigns can be signed off before product teams have even had any input!
- Specialist does not have an accessibility job title, but has taken it upon themselves to improve the accessibility of the projects they are directly involved in and sometimes related projects. The problem with being seen as the ‘accessibility person’ on a team is there is a risk that the responsibility for accessibility will be seen as theirs. If something goes wrong then they are in the firing line, and this is never fair. Specialists often front-line designers or developers and don’t have the ability to influence policy, such as mandating particular standards are met, and aren’t able to allocate funding for things like training or usability testing Additionally, accessibility can have a bad reputation, and it is easy for these specialists to be seen as the enemy, always pushing for accessibility in planning meetings, even if their fighting against the tide.
- A consultant has accessibility in the job title. It is what they are paid to do. / Outsourced responsibility / Anecdote: iPlayer web (later on mention SMP as the good but NOT here) Too little too late Works on remediation more than planning, design, execution, and training Focus on a product rather than process Works on remediation more than planning, design, execution, and training Consultants are hired to audit products, not fix processes Focus on specific product, not a range of products on a shared platform Does not embed responsibility with the organisation Lack of organisational understanding Lack of knowledge of business requirements, priorities, process, available resources, level of knowledge, culture. Also user experience expectations, documentation, written requirements. Lack of transfer of skills One off engagement Benefits don’t exist beyond the current team or timeframe Tunnel vision (too focused)
- We defined silos in terms of disciplines, and that separates everyone out, so we want to look at how we can bring people together for a better outcome. The solution is to change to a process that is based on integrated accessibility.
- Having accessibility that is integrated into the way things are done every day, rather than being a special task, can dramatically included the quality of your product from an accessibility standpoint. There are 6 areas that we believe are important to move from silos to an integrated accessibility approach.
- What it isn’t: A set of documents, how to’s and guidelines. A separate set of processes and activities. It’s integrated into existing processes and in many cases augments processes or highlights where a process is weak or doesn’t exists. It takes time. It’s OK to start small and build it out. Let’s people know what they are responsible for, how to achieve this and measure success It represents an organisational change rather than just fixing processes Have to adapt to new circumstances and not treat it as a checklist It takes time, and that’s OK; you don’t have to start big, you can start small e.g.: might be a conversation between devs and designers might be focus on a single product to pilot new processes (refine, repeat, refine) Start with training - I was embedded in a couple of products as a con at BBC. Ian was a dev of a different single product we worked formally on training and standards initially.
- Accessibility fails without governance Accessibility is the responsibility of someone with the ability to make decisions and changes across an entire organisation Not just a ‘Head of Accessibility’ but a higher being e.g. CFO at BBC Why? This person needs to be able to make change, they don’t have to ask or influence anyone higher up. Layers of responsibility Product Owners, not Accessibility Team E.g. Head of UX may be doing a fab job at implementing accessibility in UX teams but won't have that impact across dev teams for example. Resourcing: can’t give people responsibility unless they have the appropriate skills and resources
- Unless everyone in an organisation cares about accessibility, accessibility will suffer. If the CEO or CFO why should anyone else? And without good top down management support resources won’t get allocated where they need to be for training, usability testing, and other things important for the best possible outcome. Silos exist because of poor communication. Provide the tools to enable communication, which could be as simple a Slack channel, or a well managed Knowledge Base. Everyone in an organisation needs to feel empowered to question decisions. No more ‘sign-off’ from the top so that design and implementation decisions are taken away from those best suited to make them. If there’s a problem, people need to be confident that they can say so. Finally, everyone needs to feel empowered to take the time necessary to get things right. Perfect is the enemy of good as the aphorism goes, but releasing something that you know is broken damages a culture of accessibility, both inside and outside your organisation, telling everyone that an accessible product is of secondary importance.
- Are we relying on the Web Content Accessibility Guidelines to be the saviour of our products? Beyond wcag - Standards do not guarantee accessibility (or usability), but they provide a common foundation that can be use to ensure at least a baseline of accessibility Write bespoke standards or ways of meeting standards that are the best for your organisation and customers Living - Adapt and iterate standards as customer needs, technical improvements, and design styles change Formats - MAG anecdote
- How do we address the silos? Not a one off activity, must be ongoing and update to meet changes in technology, design, standards, etc. Online when suitable, onsite workshops when necessary All new starters receive training Starter training available to all Training for specific disciplines, but other disciplines encouraged to attend For example, developers can access design training Time provided Training to suit people’s needs Face to face Online Webinars Sprint 0 tasks: minimum training before starting a project Product owners responsible for establishing training needs for the team Mandatory and monitored
- Usability studies shouldn’t be a one off, never to be repeated after a site or app is live. Learning more about an existing product can help you plan improvements in to a new product from the very start Share metrics amongst teams, you’ll often find that an improvement to one site will apply to another. Usability studies / share metrics - used to provide continuous feedback, and to drive continuous improvements Bad documentation or training is often worse than no documentation or training. Keep it up to date, and keep it relevant to your organisation, and your requirements
- Ian