Design tips for internal products

A set of tips for designing internal products based on my experiences and the experiences of others.

When folks who work in IT think about the various activities involved in developing internal products, one they may not think of immediately is design.

And if you talked to product designers, many would probably express more interest in working on a exciting new B2C product rather than the more humdrum internal facing products that even those B2C companies have.

Both perspectives short change the importance of design in internal products.

I can speak from my own experience about the power of design with internal products (which I share below), but I wanted to see if my experiences were outliers.

So I did a quick search for other people who have shared their experiences of designing internal products. I came up with some great examples, which I share below.

If you have any tips that have served you well, I’d love to hear about them.

My observations about designing internal products

I also picked up some helpful tips for design in internal products, whether you have a specialized designer or not.

Here are the things that stood out to me when reading through those articles.

Outcomes for internal products

While you typically design products for growth and engagement, focus on efficiency and speed with internal products.

A good outcome for internal product may be minimizing the amount of time it takes to get through the most common workflows.

Picking the right outcome depends on understanding the business context you’re designing the internal product for.

Design for users and what they’re trying to accomplish

Because you’re designing for efficiency and speed, you need to have a good handle on their current tools, how they organize their workspace, what their frustrations are and what they’d like to improve. This is a case where what you do in discovery enables your design efforts.

It’s tempting to assume a specific setup (ie desktop with dual monitors) that users will always have to use your internal product. That worked great in the before times, but now with remote and hybrid work, that’s not assured. One way around that is to mock up the designs assuming mobile use first then use that architecture as a template to build the desktop web experience.

Design your internal product internal products in a way that guides users to do the right thing at the right time, avoiding the chance of making mistakes.

Internal products inevitably get crammed with more and more features, so it’s important to continually strive to keep the view simple and usable.

Consistent user interface and language

Although you should try to work with a cross section of users with varying experience levels, you’re more likely to work primarily with power users. Those SMEs will inevitably ask for more integrations, shortcuts, and multitasking views. When deciding what to include, make sure not to neglect the first-time user experience.

Ultimately, you want the design to be simple and standardized to a level that anyone, anywhere can pick it up and quickly start using it.

At the same time, don’t forget that most internal products have an admin component that drives the need for a small set of users to have additional capabilities. You standard design should be able to incorporate those additional capabilities for the select few users.

A key component of consistent user interface is using a common language that design and code both use. That means a common naming system based on terms that business users understand and regularly used.

Be prepared to deal with “Legacy” Software

Internal products inherently rely on a collection of other existing systems and applications. An effective design for an internal product makes the interface feel like a unified experience and hides that complexity for the user.

But product teams can’t ignore that complexity. You have to know how each of the current applications and systems connect and speak to each other. You need to know where data is buried and understand all the data sources, API’s and data pipelines.

Use design to guide development

When you work on internal products, you’re designing a system that introduces significant changes to an existing process or creates an entirely new process. So the best approach to designing the internal product is for the product team to work hand in hand with users to design the process and the product side by side.

Use mockups and wireframes to test designs before your team starts building them. You may find the design for an interface looks pretty but is a productivity drag when it’s exposed to your users’ process.

And even after your design is realized, check back and see if it works the way you expected. Observe your users actually using your product in their day to day jobs to identify opportunities for improvement.

Tips for designing internal tools

Akhil Dakinedi is a product designer at DoorDash who has had the opportunity to work on a variety of different products ranging from mobile consumer apps to enterprise web products to internal tools. Akhil notes that there’s a lot of unique design lessons you can learn from working on internal tools, and decided to share what he learned.

Akhil used Lyft’s Twilio Flex instance as an example throughout these tips to illustrate the principle. His goal is to provide a good starting point for anyone looking to learn more about designing internal tools, so hopefully you find them insightful.

Lessons learned from designing internal products at the iconic

Between 2018 and 2021 Naomi Holme worked at THE ICONIC where she designed internal enterprise applications that the company used today to manage their buying, planning and production processes.

Naomi shared her key learnings in a pair of articles (5 Lessons Learned and 5 More Lessons Learned) in the hopes that 1) you might relate and share your own stories & learnings about how you’ve tackled designing internal products and 2) the articles reignite the conversation on internal product design, and what considerations need to be taken by the designer and the business to make the products & system architecture a long-term success.

Naomi is now a Principal Product Designer at OVO Energy.

How to design internal products that are actually useful

Like any other product, an internal product is for the user: it needs to work for them to be able to achieve an outcome.

There’s a myth that spending a lot of time researching and designing internal products isn’t as important as customer facing products. This means that there’s never enough time given to it, and things are simply shipped as fast as possible in order to increase the team productivity.

This may result as an immediate value and initial increase of productivity, and if something goes wrong, that would only impact internal users, no big deal.

But what normally happens is an accumulation of quick wins on top of each other until you finally end up with a “Frankenstein tool” that looks more like an agglomeration of buttons rather than something actually usable. Creating such tools can be dangerous. They’re more focussed on “adding a new feature” rather than solving a user problem.

Nicolo Arena, a Product Designer at WhatsApp, shared a set of guidelines for designing internal products based on the idea that an internal tool should be researched and designed the same way a customer-facing tool is done, keeping the user at the centre.

Working with designers on Internal Products

I suspect if you asked a collection of people who work in IT, you’d get just as many people who say that designers aren’t necessary as you do people who say they are.

I’d suggest the former group is wrong.

I’ve always had the impression that internal products can gain a great deal from the involvement of designers, even though most companies don’t act like they are necessary.

Over the past few years, I’ve had a variety of experiences, both good and bad, that have confirmed my impressions. I thought I’d share a few of those experiences.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent