Use the arrow keys to navigate between menu items.

Inputs vs outputs

2 minutes read

I have a guitar on my wall, but can't play it very well.

When I was younger, I took some lessons from my neighbour. He was a music teacher. I had an old acoustic guitar and it worked well for practicing. I picked up a few chords and a few songs.

A few years back, I bought an electric guitar. An SG custom, similar to the one AC/DC lead guitarist Angus Young plays.

I wanted to play rock songs really really well. So that's what I started focusing on.

Needless to say, I got very frustrated day after day because I couldn't get the chords right and my fingers were never in the right position at the right time. And they hurt. A lot.

And that's the main reason the guitar is now on my wall, barely used.

Here's the thing.

Focusing only on "I want to play rock songs really really well" isn't very actionable.

That's an output and I would have done a better job working backwards from it to figure out the inputs.

What are the inputs to playing the guitar? Regular effective practice, proper technique and basic understanding of music theory.

Go deeper.

What are the inputs to regular effective practice?

Consistent daily sessions where I focus on repetition of difficult passages and following a structured learning plan.

What are the inputs to proper technique?

Correct hand positioning, efficient finger movements and general posture.

Each step backward gets me closer to things I can actually control. Like "practice for 30 minutes every day" or "work on finger placement exercises." These are specific actions that feed into the ultimate goal.

What about accessibility?

Focusing on inputs means looking beyond the desired output of "making the product accessible." It means working backward to identify concrete inputs. Good examples are:

  • requiring accessibility acceptance criteria for all user stories before development begins
  • allocating budget specifically for accessibility testing tools and resources
  • building in dedicated time for accessibility reviews at key project milestones
  • establishing clear accessibility responsibilities across team roles

Of course, these trickle down to the individual roles. Developers can worry about proper heading structure and keyboard navigation. Designers can make sure there's sufficient colour contrast. And QA can look at screen readers when testing.

That's who you embed actionable practices in your workflow. That's how you create a sustainable process that produces consistently accessible results over time.

Control the inputs.

And let the outputs take care of themselves.

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.