To Package a Great User Experience, Start with Your Development Team – InApps Technology 2022

Software developers spend a lot of time — or should — thinking about how to create a great user experience for their customers. Bitnami software engineer Bridget McErlean gave a talk at analyst firm’s RedMonk’s Monki Gras, held in London last month, that stressed the importance of packaging (the theme for this year’s conference) great developer experience, starting with our teams first.

Customer success starts with creating a delightful experience for our own development teams, McErlean contended. Only then can we ship software that reflects that better end developer experience. Never Forget: While a culture is made of people first and foremost, tools dramatically impact company culture.

“We want the convenience — not to do repetitive tasks,” McErlean said.

Like with all good development, you need to free up developers to get creative by automating as much of regular tasks as you can. She offered five steps for delighting developers and, in turn, their customers.

1. Documentation

As we’ve talked about before and we’ll talk about again, documentation is essential to the developer experience. In fact, it’s often what developers say is the most important factor in their decision making. Frankly caring about documentation shows you care about the developer.

“Reading the code shouldn’t be the first thing people have to do to understand what it does,” McErlean said.

Since documentation is so important, how do you then foster a culture of writing documentation?

Start out by automating what you can and then creating a process. Documentation is something that requires discipline, she said. So it’s up to you as the project lead to identify what interruptions are constantly being pointed to as excuses for not completing the documentation. Then, you can put an investment into your documentation, looking to first solve and reduce those interruptions, making documentation the way you address repeated issues and make your customers more autonomous.

2. Diagnostics

Any tool you are building can only prove its value if you can measure its benefits. It’s important to build with analytics in mind, so your users then understand your end users, as well as your developers, gain insight into your users.

This is also important when deciding which tools to use, as these insights are important for the team to learn how you’re all using it, so you can find new ways to optimize your workflow, collaboration and automation.

3. Defaults

Speaking of workflows, it’s also important for your team to uncover what workflows your users are following by default. McErlean advised, “Research how customers are really using your tools and polish out the workflow of those cases.”

This involves asking this important question: What do they need to remember to use the tools? Which of course comes back to better documentation and knowledge-base resources, and, in the end, building simpler tools to use.

4. Delivery

How do you make these tools available to your teams? How do you onboard new team members to use these tools?

“That’s where packaging is really important, to have a consistent way for your teams to access your tools. Make them available in one place or even better make them available in Docker containers and they can just download that image and start running them,” she said.

She went on to remind us to also think about the updates and installation experience. How will these tools be installed, uninstalled and updated across the team? How do you handle credentials? These are all small things that can contribute to big frustration and obstacles.

5. Delight

And developer experience all comes down to this word: Delight.

“Create delightful experiences for your teams and allow them to create a delightful experience for your customers,” McErlean closed with.

After all, that’s what it’s all about, right?

Feature image via Pixabay.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.