Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    Users First, Not Tools First

    Case study — the first internal release of a low-code platform worked well for the engineers migrating to it, and feedback from a solution designer showed what newcomers would need. Adding docs and onboarding was the easy part; the lasting change was building requirements from real users instead of from the stack.

    Seedcase studytended planted 2 min read

    🌱 A rough idea, planted recently. Expect rough edges — it will grow.

    On this page

    Context

    At Sky I was UI Lead on a low-code network automation platform (Building a Low-Code BPMN Workflow Platform). It was meant to let network engineers design and provision network capabilities without writing code. We released a first MVP internally.

    Problem

    Engineers moving their workflows over from the legacy system found it easy. Then a solution designer, new to the tool, gave me the most useful feedback of the release: as a newcomer, they needed a way in. Fuller page documentation, a first-use journey and in-context help weren’t there yet. The people migrating already knew the domain and the old tool, so they never needed any of that, and we had only really designed for them.

    What I did

    • Treated the feedback as a gift. It came from exactly the kind of user we’d want next.
    • Fixed the immediate gap: documentation, a first-use journey and in-context tooltips.
    • Changed how I write requirements. I’d been thinking of the platform as the sum of its tools: frameworks, component libraries, the workflow engine. Now I start from real users: business requirements tied to real user stories, and feedback taken directly from users as often as I can get it.

    Outcome

    New kinds of users, not only engineers migrating from the old system, could pick the platform up. The habit outlasted the project: the design sessions with end users for a graph library (Building a Graph Component Library), schemas shaped around how domain experts think (Keep the UI Dumb: Let Domain Experts Publish Schemas), and client feedback driving in-app guidance all come from it.

    What I’d do again

    • List every user group before the first release, including the ones who’ll arrive later, not just the first adopters.
    • The loudest early feedback comes from your easiest users. Seek out the person who finds it hardest.

    What I’d do differently

    Run a short usability session with someone from each user group before the MVP, not after. Ten minutes watching a new user is cheaper than a release they can’t use (Golden Paths).

    Platform Adoption - Business Case and Rollout Rhythms · Where Platforms Fit: DDD Subdomains

    • #user-research
    • #onboarding
    • #platform-engineering
    • #requirements
    • #feedback
    • #case-study

    Nothing links here yet — it’s a fresh shoot.

    ↪ Links to (6)