This article is based on a first-hand account originally published on puppet.com by a UX design intern who spent a year working at Puppet’s Belfast office on the Puppet Remediate product team.
Background: Joining Puppet as a UX Intern
Walking into Puppet’s Belfast office for the first time as a UX design intern is a memorable experience — not least because infrastructure automation is about as far from a typical design school curriculum as it gets. Puppet operates in a technical domain where the users are engineers, the interfaces include CLIs and APIs alongside GUIs, and the problems being solved are anything but simple.
The intern joined the team building Puppet Remediate, a product focused on vulnerability remediation across infrastructure. Day-to-day responsibilities in a multidisciplinary team ranged from gathering and assessing requirements with product managers and engineers, to conducting user research, designing new screens and UI components, and iterating on features based on real user feedback. For a brand-new intern, the learning curve was steep — but the environment was genuinely supportive.
Looking back after twelve months, three lessons stand out as particularly transferable — not just for aspiring UX designers, but for anyone joining a DevOps or infrastructure-focused product team for the first time.
Lesson 1: Design Is Universal
From the very first week, the intern was working on a live product. That is simultaneously thrilling and intimidating. The technical domain was unfamiliar, and so were many of the job’s practical responsibilities — writing design specifications for developers, building components for a shared design system, and navigating an established product with its own history and conventions.
One early project involved running hallway usability research — an informal but effective technique where you ask colleagues in passing to complete short tasks and share their reactions — to help improve the product’s navigation. Getting the entire Belfast office involved in those sessions helped make an important discovery: design principles apply regardless of the subject matter. Whether you are designing a consumer mobile app or a tool used by infrastructure engineers to manage vulnerabilities across thousands of nodes, the fundamentals hold.
The critical insight is this: invest at least as much time defining and understanding the problem as you spend solving it. Jumping to solutions is a common trap, especially in fast-moving product teams. Resisting that impulse — even when everything feels new and unfamiliar — is where strong design starts.
Lesson 2: Design Is About More Than an Interface
Puppet’s users interact with the product through multiple surfaces: graphical user interfaces, command-line tools, APIs, and the Puppet language itself. Each of these involves design decisions to varying degrees, and each places different cognitive demands on the user.
This breadth forces a shift in how you think about design. It is tempting — especially early in a career — to focus heavily on visual polish. But in a technical product context, the more important question is almost always: what problem is the user actually trying to solve, and how do we get out of their way?
Working on tools used by experienced engineers taught the value of embracing complexity rather than hiding from it. Effective UX design in a DevOps context means:
- Understanding the user’s mental model and workflow before touching a wireframe
- Accepting that a CLI workflow may serve a user better than a GUI for certain tasks
- Designing for efficiency and clarity, not just aesthetics
- Building from the user’s experience upward, rather than from visual ideas downward
Being a designer in a real product environment means adapting to shifting priorities, technical constraints, and release timelines. The theory matters, but so does the ability to stay grounded in what users actually need right now.
Lesson 3: Design Does Not Exist in a Vacuum
Academic design projects have the luxury of clean problem statements, unlimited time, and no external stakeholders. Industry does not. Every design decision at Puppet involved balancing at least four competing forces:
- User needs — what do users actually need to accomplish their goals?
- Business goals — what outcomes does the organisation need from this feature?
- Technical constraints — what is feasible given the current architecture and team capacity?
- Release timelines — what can realistically ship in this iteration?
Knowing where to compromise — and where not to — requires constant collaboration across the full product team: engineers, product managers, other designers, and occasionally customers directly. The ability to communicate design decisions clearly to non-designers, and to genuinely absorb engineering feedback rather than defend every pixel, turns out to be just as important as the design craft itself.
Perhaps the biggest adjustment from university to industry is recognising that a well-reasoned design decision made collaboratively and shipped on time is almost always more valuable than a perfect design that arrives too late. Iteration, not perfection, is the mechanism of progress in a product team.
What a Year in a Technical Product Team Actually Teaches You
The cumulative effect of twelve months on a live DevOps product — working as a genuine team member rather than a peripheral intern — is a shift in how you approach problems entirely. The instinct to jump to a solution gives way to a habit of asking better questions first. Confidence grows not from having all the answers, but from knowing how to find them and who to ask.
The experience reinforced several habits that are worth carrying into any product role:
- Stay humble. No design is ever finished. Treating feedback as information rather than criticism is what separates designers who grow from those who stagnate.
- Seek feedback early and often. Hallway research, design critiques, and engineering review sessions are not obstacles — they are the mechanism by which good design gets made.
- Take a holistic view. The best design decisions account for users, business needs, technical reality, and team capacity simultaneously.
- Iterate, don’t isolate. Working in a silo produces work that looks coherent on a screen but falls apart under contact with real users and real code.
For anyone considering a UX internship in a DevOps or infrastructure software company, the unfamiliarity of the domain is not a reason to hesitate — it is the point. Complex, technical problems are where design thinking adds disproportionate value, precisely because the instinct in engineering-led organisations is often to skip straight to building. A designer willing to slow that process down and ask the right questions first is an asset, regardless of how much they know about Puppet manifests on day one.
Originally published on puppet.com. Reproduced with reference to the original account by a Puppet UX intern, Belfast office, 2018–2019.