用于测试残疾人解决方案的研究模板
用户研究一直是 Shopify 设计过程的核心部分。但是，直到最近，我才以记录员或次要主持人的身份参加会议。
今年，这一切都变了。通过与无障碍测试平台 Fable的合作，我为我的项目开发并执行了四个研究会议。因此，该团队能够成功改进 Shopify 电子邮件产品体验，使其更具包容性。
作为产品设计师，在用户研究测试中从 0 到 60 是一项艰巨的任务——尤其是在我刚刚学习的领域（为可访问性设计）。在这篇文章中，我将与使用辅助技术的人分享我如何利用用户测试——这让我通过在设计过程的每个阶段获得第一手反馈来改进 Shopify 电子邮件——并建议一个模板，您可以使用它来规划自己的用户测试。
花时间整合包容性用户研究，不仅仅是应用 “最佳实践”，对于确保产品可以被更广泛的受众使用是非常宝贵的。最难的部分才刚刚开始。
Shopify 电子邮件最初是以某些辅助技术用户无法访问的方式构建的。特别是，我们注意到只能使用鼠标才能向电子邮件添加新部分。这意味着一些使用替代导航的人、大多数屏幕阅读器用户以及仅依赖键盘的人在自定义电子邮件方面受到限制。
这是一个巨大的问题：我们约有 15% 的商家自认为有视力障碍。
在最初的体验中，添加电子邮件部分仅在部分之间悬停时可见。
Additionally, the tab sequence navigation and labeling for screen readers needed refinement to allow those users to complete core task flows within the app more easily. To make our product more usable for more merchants, we sought to advance Shopify Email to better meet the Web Content Accessibility Guidelines (WCAG).
Some of the key considerations I established with my team were:
- Introducing a keyboard shortcut wouldn’t be enough to make the product accessible; the option to add a section needed to be a permanently visible action.
- A new “add section” solution should consider future mobile feasibility.
- The tab sequence should follow best practices and provide a logical way to move between sections and their corresponding settings.
To enable blind and low-vision users to add a new section to their email template, we added a permanently visible button in the Editor. We also maintained the hover-over behavior for those already familiar with that way of doing things.
A new permanently-visible button was added to the email Editor.
The hover-over behavior was maintained for those people already familiar with that way of working.
In parallel with these changes, we updated the labelling and tab sequencing to ensure alternative navigation users were able to move around the app more easily.
To ensure the usability of all of these improvements for people using assistive technologies, we ran four research sessions with Fable testers.
Fable is a user testing platform that facilitates recruitment of professional testers to help explore and vet solutions at all stages of fidelity.
All testers are people who use assistive technologies and some even have a technical background to offer implementation recommendations. (And, yes, all are under NDA.)
We piloted using Fable at Shopify in 2019 and again at the end of 2020. It’s been used by the Retail team for interviews, and by other teams for checking products after they’ve been built. The Email team is the first team at Shopify to use Fable more broadly, with multiple requests across different design stages.
Shortly after kicking off the project, we engaged the Fable community over the course of two months. Each round of research (four in total) took about 3–4 days to complete, accounting for recruitment time. (Because the Fable platform operates almost like a marketplace, finding testers was always the easy part once I submitted a research request.) While I ran point on three research sessions, the lead engineer on the project also stepped in to lead his own session.
To familiarize myself with the Fable platform, and help the team learn common preferences of folks using assistive technologies, I ran several informal, educational interviews. After I had a loose concept of a solution in mind, I conducted co-design sessions with Fable testers to validate the approach before polishing high-fidelity prototypes. When we were refining the tab sequencing solution, our lead engineer took the lead on a more casual implementation discussion with a Fable tester who had technical expertise. And finally, once the solution was live behind a beta flag, we conducted a few unmoderated sessions with testers running through a simple task flow.
After every research round, I would aggregate insights into a short, high-level deck to share with the project team for visibility. Although the research sessions did not surface any major red flags, they did help us build confidence that our solutions were actually accessible from a human perspective — as well as a technical one.
When we initially rolled out the new button feature, we ran a 2-week experiment to track the user behavior of using the new button compared to the original hover behavior for adding a section. We saw 20% of users only used the button during their session of editing an email, which indicates that there are potentially folks who either didn’t realize they could add, didn’t know how to add, or were not able to add sections before this button existed.
Although the long-tail impact of this button since launch doesn’t indicate that merchants are adding more sections overall, the team is confident the improved experience has enabled more merchants to use the app successfully based on our initial experiment after launch.
This project was my first experience running this type of usability testing. While the project helped us successfully make our Email product more inclusive and usable, we’re still trying to work out a usability testing workflow that scales for all our projects.
Here are my tips and takeaways from the experience:
- Familiarizing myself with common challenges and user behaviors for folks using assistive technologies — before imagining a solution — helped build empathy and changed the lens I used when initially envisioning a solution.
- Vetting our solution from both a usability and technical perspective ensured an experience that was accessible from both a human-centric and compliance-centric perspective.
- Testing is easy — getting started is the hard part. Just think of your user testing like a conversation.
To help you get started, below is a useful starting point for planning accessibility testing at every design stage.
This template outlines a series of four research sessions, conducted at each design stage, to help successfully validate your products and solutions with people with disabilities.
Session 1: Informational interviews
What: Casual 1:1 conversations to understand common challenges for people using assistive technologies (AT).
When: Before exploring specific solutions to the problem at hand
Who: 3 users: 1 screen reader, 1 screen magnification, 1 alternative navigation (voice control)
Why:
- To get your feet wet using Fable and get comfortable conducting UX research
- To understand the general preferences and challenges of folks using different AT
- To get a quick “first impression” review of the existing product experience from folks using AT
How: Casual Q&A followed by a very basic task flow within the product overall.
- Start with a quick company overview, and context about the specific product or app for the testers
- General AT preference questions, to educate yourself and your team
- High-level, guided task flow
Research questions that helped inform a detailed script:
- What kinds of assistive technologies are folks using to interact with web applications?
- What are their preferences in terms of using those technologies?
- What are the frequent pain points they have? What do they consider characteristics of great experiences?
- What does the product or app look like/how does it behave when using AT?
Session 2: Design review/concept preview
What: Moderated user interview to validate a proposed concept or solution
When: With initial screen mockups, before build begins
Who: 3 users: 1 screen reader, 1 screen magnification, 1 alternative navigation (voice control)
Why:
- To identify any potential pitfalls in a proposed design, before moving into high-fidelity prototype and design
- To vet initial impressions and user sentiment about solution
How: Quick Q&A followed by a guided task flow with the proposed solution
- Start with a quick company overview, and context about the product for user
- General AT preference questions
- Share Figma link (or screen share your mockups) to get initial impression of solution
General format of questions while showing prototype:
- Based on this mockup, how would you go about [doing some task]?
- What would you expect to happen when you do that?
- Can you tell me your impression of this mockup at this point?
- What do you think about the experience around [doing that task] based on this mockup?
Research questions:
- What is lacking or misaligned with their expectations of how the proposed flow should work?
- Is the potential solution accessible from a human (versus technical) perspective?
Session 3: Implementation validation
What: Collaborative discussion between engineering and Fable tester to discuss implementation.
When: After build begins, before launch
Who: 1 screen reader user
Why: To quickly test and discuss the technical implementation of our solution (in particular, labels and behavior for the tabbing sequencing)
How: Informal discussion led by engineering
- Demo solution for user
- Discuss any pitfalls and plan ways to address them
Session 4: Compatibility testing
What: Unmoderated testing of the solution to ensure users can complete the task at hand.
When: Just before launch, when solution is usable in beta
Who: 5 random users of different AT (i.e. screen reader, screen magnification, alternative nav)
Why: To validate that our implementation technically and functionally supported the core task flow for most users
How: Unmoderated user test in demo store
- Provide login credentials and specific 10-step task flow for users to test
- Include company and product context brief with login instructions
- Create any foundational drafts or individual test environments to provide as a base for each user flow
Research questions:
- Can users accomplish the core task using their respective assistive technology?
- 体验是否满足辅助技术用户的期望？
https://ux.shopify.com/how-to-test-for-accessibility-with-users-at-every-design-stage-ec655fed7878
若有收获，就点个赞吧
0 人点赞
