ANODA Discuss your product

Developer Tools & Infrastructure UX Design

Design the consoles engineers use to connect, watch and fix their systems — so the first setup works, the right signal stands out, and an incident reads in minutes.

Discuss your product Explore our work
A steel robotic arm on a wheeled base lifts an orange wrench out of a white ceramic toolbox beside a terminal slab.
Setup to diagnostics
The whole console, not one screen
Dense data, readable
Tables, logs and dark mode included
Habits kept
Live tools refreshed without moving controls
Custom scope
Fixed or phased, set in the proposal

In short

Technical products engineers can set up, read and debug, without a wall of numbers or a trip to the docs.

What's included

  • Setup and configuration
  • Observability views
  • Diagnostics and logs
  • Information hierarchy
  • Keys, roles and access
  • Dense tables and dark mode

Answers you'll have before development

  • What must an engineer see first?
  • Which setup step loses the most people?
  • Where does the console stop and the CLI take over?

Where it stops

Dashboard Design

One screen of charts and figures for the people who monitor.

Developer Tools & Infrastructure UX

The whole tool engineers configure, watch and debug in.

Not included

  • API, SDK or CLI design, or documentation
  • Adoption or uptime figures

The console built around the engineer's job

Developer tools go wrong when screens mirror the back end. The design starts from what engineers do — connect, check, investigate, change — and shows the system in that order.

Discuss your product
  • Three ceramic pawns on a board, each on its own steel rail of steps, the rails meeting at one graphite block.

    Workflow and role map

    Setup, daily checks, incidents and admin, per role — from the first connection to on-call.
  • A ceramic plug with steel prongs lifted from one ceramic socket towards another, its short cable graphite.

    Configuration and onboarding flows

    Connecting a first cluster, key or integration, with validation and a clear error at every step.
  • A ceramic tablet carved with a rising line under a dashed target line, on a steel stand, a ceramic hourglass with graphite sand in front.

    Observability and diagnostic views

    Overviews, graphs, tables and logs, ordered so what is wrong surfaces first.
  • A shallow ceramic tray divided by a steel grid, holding ceramic buttons, a card, an input field and a toggle, one graphite piece lifted above its slot.

    Dense UI and component set

    Tables, code blocks, statuses and dark mode, as one set of parts every view shares.

You receive

  • Workflow maps for each role
  • A state and permission matrix
  • UI and a clickable prototype
  • A component kit, dark mode included

Designed for the engineer on call, not only the demo.

Developer experience design is tested when something breaks. Every screen is drawn for the quiet day, the noisy alert and the half-loaded metric, with the detail one click away and never hidden.

Every screen is designed for

  • Nothing connected yet
  • Validating a connection
  • Connection failed, with the reason
  • All healthy, nothing to do
  • Alert firing
  • Key expired or access denied
  • Metrics stale or partial
  • Risky change awaiting confirmation
  • Thousands of rows, one filter

When developer tools design is the right frame

It fits when engineers are the users, and the product is how they run their systems.

  • Engineers are the users

    They judge the tool in minutes and fall back to the CLI if it wastes their time.

  • The data is dense

    Metrics, logs, configs and states that change by the second.

  • Setup is where people drop

    Connecting the first cluster, key or integration takes too long.

  • The views grew apart

    Each module has its own tables, statuses and patterns.

A different starting point

Let's make your tool as sharp as the engineers who use it

Tell us what the tool does and where engineers get stuck. We will come back with the service that fits and a realistic next step.

Discuss your product Explore our work

Scope, access and who does what

Developer tools are usually designed a workflow or a module at a time, through the service that matches the tool's stage. Its proposal sets the terms.

Scope
Per service fixed or phased, set in the proposal
Timeline
Agreed after scope, access and dependencies
Discuss your product

  1. You provide

    The tool
    Staging filled with realistic volumes of data, and a login for every role.
    The engineers
    Time with the people who set it up, watch it and get paged by it.
    Decisions
    A product owner who can settle what the console does and what stays in the CLI.
    Engineering
    What the back end can report — metrics, latency, errors — and how fast.

  2. Who does what

    ANODA
    Maps the workflows with the engineers who use the tool, designs the flows, states and screens, and hands over a component kit.
    Your team
    Gives access and context, reviews each step, builds the console and its APIs, and ships it to users.

  3. Boundaries

    Outside developer tools design
    Development, API, SDK and CLI design, documentation writing and infrastructure work.
    After the design
    Your team builds the console. A review of the built console, if you want one, is a separate scope.

Related services

Product types

Industries

Where do engineers give up on your console?

Tell us what the tool does, who uses it, and which step sends people back to the CLI.

What do you need? *
Project budget (USD) *

What is your product, who uses it, and what would you like us to do?

    Within 15 minutes, we’ll reply with initial feedback and follow-up questions.

    Read more about designing technical products

    All articles

    Developer Tools & Infrastructure UX: common questions

    Our users are engineers. What should a design team show us before we trust it with our tool?

    Ask to see a technical product designed end to end: a setup flow with its errors, a dense table at real volume, an overview that ranks what is wrong, and the states around them. Ask whether the team spoke to the engineers who use the tool, how it treated dark mode and data density, and what it left unchanged in a product people already know. Our Superstream and MantisHub cases show both a new system and a careful refresh.

    Where does DevTools UX design start on a console like ours, and what adds to the work?

    A map of who uses the tool for what, the setup and onboarding flows, observability and diagnostic views, the UI as a clickable prototype, and a component kit. The work grows with the number of modules and roles, the density of the data, whether dark mode and tablet are in, and how much of today's tool stays as it is. They are set in the proposal for the service you start with.

    Who uses an infrastructure tool, and which of their jobs does the design have to cover?

    Platform and DevOps engineers who connect and configure, developers who check their own services, on-call engineers who investigate alerts, and admins who manage keys, users and billing. The workflows are the first connection, reading an overview, drilling from a spike to the cause, changing a setting safely, managing access, and reviewing what changed and who changed it.

    Which ANODA services fit a developer product, and where do we start?

    A UX Audit shows where engineers struggle in a live tool; Product Redesign gives a well-known tool a new surface without moving its controls. UI/UX & Product Design fits a new developer product built from scratch, Web App Design the console, Dashboard Design a single monitoring screen, and Design Systems the parts every view shares. UI Design carries the visual layer when the structure already works.

    How do you handle dense data, errors, permissions and edge cases?

    With the workflow, not after it. Every screen is drawn for nothing connected yet, a connection being validated or failing with its reason, all healthy, an alert firing, an expired key or denied access, stale or partial metrics, a risky change waiting for confirmation, and thousands of rows under one filter. Roles decide who can change what, and dark mode is designed for readability, not inverted.

    What do you need from our team to start?

    Staging access with realistic data and a test account per role, time with the engineers who set the tool up and get paged by it, a product owner who can decide what the console does, and the engineers who know what the back end can report and how fast.

    Which developer and infrastructure products have you designed?

    Superstream, a Kafka management platform for DevOps teams — 3000+ screens designed and 1500h+ design hours by 4 experts. MantisHub, the hosted issue tracker built on MantisBT — 52 screens by a team of 3. The case studies show how dense technical data was made readable.

    Engineers already know our tool by heart. Can you change it without moving their controls?

    Yes. Most developer tools are live, and their users have habits worth keeping. On MantisHub we redesigned selected workflows and kept the dense lists and filters experienced users depend on. We work in your files and components, review with the engineers who use the tool themselves, and hand over the kit the console is built from.