Weeknotes – series 06 episode 07
- Author Benjy Stanton
This was my first week back after my holiday, and I went straight into my first client assignment at Made Tech. I’m also half way through my probation.
Native app design
For my first assignment, I’ll be working on a native iOS and Android app, and I have just over one sprint to handover with the existing designer before they leave at the end of the month.
We’re spending time having handover meetings whilst I get to grip with the regular sprint meetings and ceremonies. Next week, we’re hoping to do some shadowing.
The existing team uses Sketch for designing, and Zeplin to hand over the designs to the engineering team. Although this workflow isn’t my (or Made Tech’s) first choice, it looks like it’s working well.
Apple publishes a lot of their design resources in Sketch format, so I think this is one reason that app designers use Sketch.
Here are some resources…
- Sketch library, design templates and production templates
- SF (San Francisco) Fonts
- SF (San Francisco) Symbols
The apps follow native design patterns, so it’s been recommended that I get familiar with Apple’s Human Interface Guidelines and Android Material Design system. This helps to take advantage of the operating systems’ built-in accessibility features.
Accessibility best practices
I’ve been getting to know the rest of the team, including the user researchers and engineers. It’s been great to get back into hands-on delivery work. I’ve been chatting with the user researcher about how we can include people with access needs in the next round of user research.
And it seems like improving the definition of done and acceptance criteria will be one of the key ways to make sure engineers can pick up designs and really understand the intention of the designs when they implement new user stories.
I’ve been gathering some resources about how to document accessibility…
- How to write user stories for accessibility - Tetra Logical
- How to write accessibility acceptance criteria - BBC
- Improving accessibility with accessibility acceptance criteria - GOV.UK
Also, inspired by some work my old team did at UKHSA (UK Health Security Agency), I’m putting together a list of accessibility practices and behaviours that are needed on a team in order to deliver accessible services. This is still a draft, but shared here as a work in progress…
- Identify excluded groups and their pain points
- Do user research with people with disabilities and other excluded groups
- Use native app design patterns and components
- Continuously run accessibility tests
- Get an accessibility audit
- Publish an accessibility statement
- Gather performance data and analytics in a way that includes everyone
Reading about inclusive design
I was reminded that I can spend my Made Tech learning budget on books (amongst other things) so I bought a copy of one that I’ve had my eye on for a while…
Just a few pages in, and I can’t believe I didn’t get it sooner. It reminds me of Why I’m no longer talking to white people about race for the way it cuts straight to it, and really helps me to understand oppression and privilege (only this time it’s focussed on design). Bonus points for how beautiful it is.
I’m collecting further reading resources about inclusive design over on my Github Gists page.