Developers talk, Puppet listens
Chances are, at some time or other you’ve had one of those experiences with enterprise software, the kind that makes you wonder how a product could possibly have been put together with a human user in mind. And we don’t discount the possibility that the product may have been Puppet ;)
Without investment in a positive user experience, all the effort is left to the poor person sitting in front of a screen, wondering how they are going to get their work done. At Puppet, the principles of user-centered design are paramount. Humans are going to be using what we build, so it’s humans we work hard to design for.
You really don’t have to look too far anywhere in the world to see huge technical and engineering accomplishments diminished by a lack of real provision for end users. Think of the parking machine that requires you to stare at it for two minutes before you finally understand which button to push first. Or maybe the banking app that left you fumbling around for a simple way to set up a new transfer.
What helps us design for humans is the fact that so many of the people who work at Puppet are themselves current or former users of the product. That said, we try not to make the mistake of relying just on the knowledge inside the business to generate insights.
That's because when engineers build things for other engineers, it can be very easy to assume everyone is a power user. To avoid this kind of friction, we consult directly, regularly and systematically with Puppet customers and users. The insights we gain this way feed directly into improving our products.
Providing a platform and associated tools for others to build on is a fascinating challenge. We call it the Puppet developer experience (PDE). It’s not just a name; it’s a commitment on our part to provide those developing on the Puppet platform with the best possible experience. We dedicate whole teams of product owners, engineers and UX architects to this goal. If we get it right, people using Puppet will be able to finish their tasks more quickly, achieve their goals more effectively, and get on with the rest of their work.
So how does this look in practice? A good way to show you is to describe the work we've been doing recently on the Puppet Development Kit (PDK), which is designed to help you create Puppet modules more easily. (Note: This hasn't been released yet, but we'll be releasing it soon. Watch this space!)
During the process of building the PDK, we consulted at intervals both internally — with engineers at Puppet — and externally, with customers who use Puppet in their daily routines.
We surveyed Puppet users to find out if and how they currently test their code. This is how we learned that people were testing their code with 40-plus different tools, and that developers were overwhelmingly (more than 90 percent) dissatisfied with their current methods. Some wanted Puppet to write a tool, but most simply wanted us to suggest or prescribe the best way to test modules. From this we learned that there was demand for a Puppet software development kit (SDK); which testing tools were most commonly used; and which of those tools were perceived to be most effective. This discovery offered the validation we needed to pursue the project, while offering a direction of travel.
We examined the current module creation workflows (of which there are many) to identify pain points. By removing friction, we could offer an optimal method of module creation that would ease frustration and save time. Examples of these include:
- Deciding which skeleton to use
- Building a suitable test environment
- Testing and validating modules
We proposed a new optimized workflow, which the PDK should facilitate. This workflow was reviewed and vetted by our engineers internally, then iterated, and finally examined for any potential pitfalls we might be creating by taking developers away from their existing workflows, however imperfect those might be. While the new test and validation commands we were introducing —
pdk test unit and
pdk validate — offered greater simplicity, it was clear we would need to make these commands discoverable and intuitive. So we realized we needed to make really good help documentation available in the console for people to use the new commands effectively.
From the optimized workflow, we created a document that we could put in front of users, essentially our MVP (minimum viable product). Over a series of interviews with customers, we noted reactions to the proposal and how much they felt it would solve problems for them, particularly around testing code. With an 80 percent positive response to the description of the PDK, we had the validation we needed to proceed.
We released prototypes internally, shared early builds with the community for feedback, and are currently conducting 1:1 testing with the pre-release version. Our internal tests range from a simple sanity check to quasi-usability testing that lets us identify some low-level issues. For example:
- In one test, we found that some prompts in the command line were obscured due to the background color of the participant's console — an easy fix, but significant from a user experience perspective.
- Another test revealed that the process of creating a class could use just that little bit more of a callout in documentation to simplify it for first-time users.
Some outcomes of all this work are ready to break cover, and we are just a few short weeks away from releasing the PDK. If you write Puppet code or you’re considering it, our goal is for the PDK to give you a more streamlined experience.
At PuppetConf 2017, we’ll be talking more about the Puppet Development Kit, and hacking on it at the Puppet Contributor Summit the day before the conference begins. We hope you can join us! If you are interested, sign up now for PuppetConf, and make sure you choose the option of including the Contributor Summit. There is no extra cost to attend the Contributor Summit, but places are limited, so sign up soon.
If you're an early adopter, you can preview the PDK by checking out the open source repository. We will welcome your feedback.
We always want more of our community to help us understand how people use Puppet. If you'd like to join in, take a look at our Puppet Test Pilots program, and jump on board. We’d be delighted to have you join us on the journey to better experiences for all.
Rick Monro is a principal user experience designer at Puppet.
- Haven't tried Puppet Enterprise yet? You can download our Learning VM for free and get a hands-on experience of how Puppet Enterprise works.