User experience fails aren't just inconvenient. When it comes to accessibility they're life-altering. Molly Burke's revealing demonstration in this video of an audio description device control app exposes the frustrating reality visually impaired users might face.

The accessibility improvement story, however, lies deeper. Product development processes sometimes prevent skilled people from creating good (accessible) products. This article examines how systemic, organizational, and individual factors set the stage for the success or failure of accessibility efforts before they even begin.

It's time to re-frame how we think about software problems that surface “in the wild” – that is, after the software is available and in “production” use. What if we stopped describing signals from our customers with reference to the development process, as bugs vs enhancements? What if instead we thought of all issues raised about released software from the customer perspective? Maybe it's time to shift to an insufficiency frame.

The “bug” frame centers figuring out what's wrong. The insufficiency frame directs our attention toward a better future for our customers, our products, our companies, and ourselves. If we can take something that's insufficient and make it adequate we've stepped onto a path that leads to ongoing improvement in products that will inspire customer trust, have a durable and sustainable market life, and enable users to work with confidence, efficiency, and effortless enjoyment.

One of the simplest and most useful user-facing functional structures for software, the Submit-Respond-Observe pattern often masquerades under different names. It’s ubiquitous and often hidden under layers of gold-plating, aesthetic frippery, and scaling (read: corporate/enterprise) features. Sometimes it’s camouflaged by useful, yet showier, features. It’s also susceptible to unimaginative user experience and user interface design. Let’s dive in.

Sometimes an organization needs more product management capacity. Maybe the organization is a growing startup. Maybe it's a more established company expanding its product management capability. No matter the reason, organizations often ask whether they should create new positions and if so, how to define them.

Product Management has a confusing array of different guides, frameworks, jargon and buzzwords, techniques, and tools. OKRs, North Star metrics, JTBD, and dozens of other concepts compete for attention, leaving both aspiring product managers and companies who need them floundering or seeking clarity. There is really only one principle you need to know:

Shorten the path to value.

Gojko Adzic and the good people at SpecFlow published a series of posts on advanced topics in Given-When-Then scenario writing called Given-When-Then With Style: The Community Challenge. And, good news for us practitioners, the “community challenge” part means it's an all-skate! Each week's post describes a specific situation that some find difficult to express in scenarios. Anyone can propose a solution. The following week's post considers some of the proposals, describing drawbacks and benefits of each, and presenting a detailed exposition of a top solution. I highly recommend the series.

This week's Pauses and Timeouts challenge is on handling situations where there is a pause or timeout in the activity. I've dealt with many situations like this, and handled it in various ways in scenarios. In one case, a shopping checkout required payment processing which eventually delegated to external service provides. In another example, an application queued report requests and notified the requestor to retrieve their report once it was ready. More recently, I worked with a system in which data modified in a mobile app was expected to appear for workers in a different role who were using a Web application to manage operations. As Adzic notes in the Pauses and Timeouts challenge, this situation “is symptomatic of working with an asynchronous process, often an external system or an executable outside of your immediate control.”

Here are a couple of approaches I've used.

(Given-When-Then Challenge #4)

TL;DR * Frequently maintain and refactor * Split feature files and organize in folders * Don't limit yourself to Connextra user story format in the description * The best description might be no description!

First, Solve the Right Problem

(Given-When-Then Challenge #4)

The latest SpecFlow Given-When-Then community challenge (#4 in the series) asks about feature descriptions. The challenge asks three different questions:

1. Should the feature description look like a user story?
2. How should features, scenarios, and their descriptions evolve over time as new personas and needs surface?
3. How to write a good description for a feature or scenario? …. How to structure those descriptions? Should they look like user stories or something else? What should they contain?

By the time I had read to the end I knew I wanted first to explore the generic/vague anti-pattern, define “reports,” discuss finding the right problem to solve, and explore how to link solution ideas to a person's needs. Only after I fully understanding these problems and questions would I be ready to offer thoughts on the challenge’s central theme of descriptions (which is in Part 2 here).