Platform feedback and adoption

Turn “easier to use” into a question

Developer experience includes finding the right action, understanding its inputs, waiting for a result and recovering from a mistake. Count those steps before deciding which one to automate. More buttons or more templates do not automatically reduce the work.

Measure the developer journey

The number of templates published does not show that developers can use them. Choose a small set of observations tied to the task: time until useful feedback, time until a verified result, help required, and whether the failure message leads to recovery.

Keep service reliability separate from platform usability. A fast form submission with a failed deployment is a failed journey. A slow attempt caused by an image download should be labelled so it is not confused with an approval delay.

Use a comparable baseline

Repeat the manual task and the templated task with the same application change, target, and definition of completion. Record cold and warm caches separately. If you are both the author and tester, say so; that result cannot establish new-user usability. A second learner can provide useful feedback, but do not infer organization-wide benefits from one session.

Suggested local evidence fields are request_id, started_at, first_feedback_at, verified_at, result, help_needed, and failure_stage. Missing observations stay missing; they are not zeros. Avoid putting credentials, account identifiers, or individual performance rankings in a public dashboard.

Interpret a small example honestly

The following times are invented for a calculation exercise, not results from this project.

The portal provided feedback sooner. The table does not establish that it made delivery faster: one attempt failed, and the successful attempt used a different cache condition. Excluding the failure would hide the most useful finding—the unclear policy message.

Try one fair comparison after the capstone: same kind of change, same target, same completion check and recorded cache condition. Separate time spent waiting for a review from time spent understanding the tool. For a self-tested lab, write “author-operated trial” rather than “developer productivity improved.”

Choose the next improvement: fix the unhelpful policy response before adding another template. That choice follows the observed difficulty, not the number of features in the portal.

Try it

At the first platform lab, save a baseline attempt. At the IDP lab, repeat the task and write a short comparison. Identify one friction point that improved and one remaining problem, or report that the portal did not help. Include the actual number of attempts and their limits.

Ask whether a developer would choose the supported path voluntarily. Document who owns an alternative route and what support it includes.

Checkpoint and revision

Which observation would make you simplify or remove an automation? Adoption, reliability, and measured task completion answer different questions. Use your observations to choose the next improvement; the lab sets no required savings percentage or maturity score.

Compare your reasoning

A failed run has no successful completion time; do not enter zero or exclude it silently. Keep counts, failures and conditions visible. The next lab captures a baseline, and the final capstone gives you a chance to compare the same task.

Sources

CNCF platform maturity model↗, DORA research↗.