2 minute read Platform Engineering

Introduction

As platform engineers, we obsess over reliability, scalability, and automation. We optimise CI/CD, enforce policy-as-code, and abstract infrastructure behind elegant APIs. But here’s a hard truth: technical excellence isn’t enough if no one wants to use what we build.

That’s where product and UX thinking come in.

Internal platforms are not just infrastructure—they are products. And platform engineers, whether they realise it or not, are product builders. To make those platforms successful, we need to start borrowing playbooks from the people who have spent decades obsessing over user needs: product managers and UX designers.

Design for Humans, Not Just Machines

Your CI/CD pipeline might be fast, but does it make sense to someone onboarding for the first time? Your Terraform module might abstract complexity, but is it discoverable and usable without reading a 20-page wiki?

UX insight: Good design reduces cognitive load.

“Don’t make me think” applies to internal tools, too. If engineers have to guess how to use your platform, they’ll either get it wrong—or worse, they’ll go around it.

Developer Experience Is the User Experience

What’s the typical “day 1” experience for a new engineer using your platform?

  • Is onboarding documented and automated?
  • Can they deploy a service in <30 minutes?
  • Are error messages actionable or cryptic?
  • Do they get feedback when things go wrong?

These are all UX questions, and they deserve the same rigor you’d apply to production systems.

Feedback Loops Are Not Optional

UX designers don’t wait for users to submit tickets. They run surveys, usability sessions, and analytics.

Platform teams should do the same:

  • Use NPS-style surveys for internal tools.
  • Track usage metrics (e.g. how many teams use your service scaffolder).
  • Conduct platform office hours to collect qualitative insights.

Warning sign: If feedback is only coming via Jira tickets or Slack escalations, you’re too late.

Apply Visual Design Principles

Even if you’re not building UIs, the concepts of hierarchy, clarity, and consistency matter:

  • Structure docs so that the most common use case is obvious.
  • Use consistent naming and terminology across services, flags, and APIs.
  • Show, don’t just tell—use architecture diagrams, command-line examples, or live demos.

Micro-improvement: Color-code logs or CLI outputs to highlight errors, successes, and warnings. It’s a small UX win that pays off instantly.

Think in User Journeys, Not Just Tools

A great UX designer doesn’t just design buttons, they design flows. You should too.

Instead of asking “How do I improve the CI pipeline?” ask “What does the journey look like from commit to production?”

Map the journey. Find friction points. Improve end-to-end, not just in isolation.

Embrace Iteration

UX is never “done.” Neither is your platform.

  • Ship MVPs.
  • Measure adoption.
  • Iterate.

Pro tip: Beta test new features with one or two teams. Collect feedback early. Build champions internally.

Empathy is a Platform Superpower

The best UX designers have deep empathy for their users. Platform engineers should too.

That means:

  • Sit with devs.
  • Watch them struggle with your tools.
  • Listen before fixing.

Don’t assume you know what devs need. Ask them.

Conclusion

The best internal platforms aren’t just powerful, they’re a joy to use. By applying UX and product principles, platform teams can create tools that developers want to use, not just have to use.

It’s time to evolve: from infrastructure builders to experience designers. Because in the end, a great platform isn’t just technically right—it feels right.

Leave a comment