5 lessons in internal product design: user assumptions, concept validation, user empathy, data modeling and design systems
In September 2018, I began my UX journey at THE ICONIC and was lucky enough to jump straight into designing internal products from scratch, on a mission to scale and grow the business.
THE ICONIC had invested in designing its own products so that we’d have the power to change them as we grow and adapt. No pressure!
Just over 2 years later, I’ve designed and launched 5 of our internal enterprise applications that are used today to manage our buying, planning and production processes. And it’s been one hell of a journey!
I’m sharing my key learnings from this steep learning curve in the hope that 1. it might help our awesome community of designers in enterprise app design and 2. you might relate and share your own stories & learnings about how you’ve tackled this beast.
1. Never assume your internal users behave anything like your customers (they don’t)
Having designed products for both THE ICONIC customers and our employees, the first lesson to learn is that you must clear your mind of one user group behaviour before moving on to the next. Seem obvious? Allow me to dive a little deeper.
One of the product missions for the 2nd half of this year was to streamline processes in the Category Management department (our buying and planning teams) so that we could scale and grow our category assortment.
This led to the decision to build an app to replace a fully manual workflow, during which members of the buying team would actually use THE ICONIC website to browse & select certain products. Having spoken to the users, we had understood that because they relied so heavily on the website to complete certain tasks, they would need a version of THE ICONIC catalog page to select the products they needed.
It worked, BUT NOT VERY WELL. We had imitated the filters and categories used on the live site, as it worked so well for them before, right? Not so.
Each buying department and sub-department has its own codes, category trees and product categorisation system, which means that the way they assign and categorise products is totally different to how it is displayed to customers to help them search & filter products on the site.
We had to then identify these buying codes across all the departments, map them to the codebase and then translate it into a neat UI with concise copy, categories and filters that would allow every user to easily search and find their specific department’s brands and products.
We got there, but if we had only NOT ASSUMED that the customer-facing categories and filter system would be the same for our internal users, it might have saved us a lot of time!
2. Validate CONCEPTS before designs
Often in internal product design, we’re designing systems for processes that don’t even exist yet — rather they’re replacing flawed or broken processes, or introducing a workflow that increases efficiencies for the wider goals of the business.
This means there’s an added complexity of training your users THROUGH the design, what this tool is for and how to use it. This was the case for an application we designed and built in Quarter 3 this year.
When you’re introducing a new workflow, it’s more important than ever to map this out HAND IN HAND with your USERS and ENGINEERS, so they know exactly what to expect from the tool.
You can almost design the process together. You are the expert in design, therefore your job is to guide them on usability concepts and how to make the job as simple as possible. The engineers guide on the system architecture, data pipelines and even existing components available in the code repository that may be suitable for this type of tooling.
Allow the user to guide you on how they visualise this process working for them and their level of familiarity with this kind of system. For example, if they love using Google Sheets to view lists of products and manage status changes, that’s key information which might inform that table design is preferred in this scenario.
As a squad (Engineers, Product Owner and Data Scientist), we ran workshops with our users to take everyone on the same journey of understanding the business plan.
From there, the most important thing to do from a design perspective is to align user expectations with best practice design principles and development effort BEFORE you design anything.
Heck, before you even draw anything. Best decision I made here? Hold a co-design session with my squad via Zoom on MIRO (quarantine edition!) to draw out how we imagine the tool to work.
With our combined domain knowledge, expertise and creativity, we were able to storyboard our solution and validate with users before any designs were done.
3. Flex those soft skills
Designing for internal users is all about trust. The more they let you in to their world, the more you understand about the problem space and the better the design solution.
I had the advantage of being a long-term employee who’d worked in a people-centric position in the business before, therefore already had good relationships with a lot of our users. But this isn’t the only way!
Building relationships with your users is an easy way to create a reliable access point to valuable information.
Equally, a point of contact to help answer any questions or doubts you may have in how their processes work.
LISTENING IS VITAL. The business has invested in you as a valuable resource to solve problems and inefficiencies in processes through design.
The only way you can do that is to give your time to understanding and empathising with your users’ pain points and needs. Just listening can be such a powerful tool in building that relationship and letting them know you hear them.
Put yourself in their shoes — they may have been struggling through complex, hard and inefficient processes every day for a long time, with no one to help them or understand how difficult it is.
Once you’re there and you see how they do certain tasks and feel the pain they go through, it gives you a great understanding and genuine concern for the problem. You’ve started building that trust with the user and they have the confidence that you GET IT.
You deeply understand what they have to go through. You’ll then have that bond and the confidence to ask ALL the questions. Never stop asking questions, even when you’re 100% sure you understand the problem.
Listen, empathise, spend time and show interest in your user’s world — it’s the best advice I can give if you want to be a great designer!
4. Don’t underestimate the complexity of legacy systems and data models. Do your homework!
Working in internal product means you have to know (REALLY know) how each of the current tools, applications and systems work and how they connect and speak to each other.
Why? Because you cannot design an application to be used at that scale without understanding WHERE THE DATA IS COMING FROM first.
Designing internal apps is like being an architect — you have to know where the water & electricity sources are (the data), how to connect it to the building (the APIs) and how your building might affect other buildings in the area (will this put too much cognitive load on our other apps and microservices?).
Without this knowledge and understanding, you’re going to be drawing up UIs that may make perfect sense to you and indeed the user, but are impossible to build. You’re trying to show information that either doesn’t exist (yet) or cannot be displayed in that format or at that stage of the user journey.
I’m going to hand over to Krisztina Szerovay who explains this beautifully through this awesome diagram (because what better way to explain complex concepts than drawing them out!):
Bottom line: study the data sources, APIs and data pipelines, map them out, investigate and map out again before you design the UX.
Become best friends with your data scientist and engineers as you will NEED THEM! You should be on zoom to them EVERY DAY until you get this!
5. Consistent UI matters — create an internal design system
Many moons ago, many of our early internal applications were built without a design system, or even a designer. This meant that the internal design components library existed entirely in code.
Lesson 1: DON’T try and emulate that through your designs. It may create consistency with previous builds, yes, but this will not create a scalable or adaptable UI suite for future designers OR yourself!
Do it right the first time, define the primary and secondary components (this should be done hand in hand with the engineers), document them, and maintain that library.
Lesson 2: Every time you create something new, be it an icon, button, label, colour or typography — create that as a symbol in your shiny spanking clean library, save it and share with the rest of the team.
I made the mistake of initially just auditing all the internal design components, documenting them in a regular sketch file and defining what should be used for what, but stopping there.
It was a copy paste game for some time. It wasn’t until I was educated later on about creating my sketch files as libraries (thanks, Sam Roberts!) that I understood the importance of creating symbols and templates to speed up and CLEAN up the process exponentially.
Instead of the old copy paste, you’re able to insert components and page sections directly from the linked library files (thanks, Abstract!).
Don’t get me wrong, we do have this for our customer-facing design system, but DON’T FORGET the internal design library — invest in doing this right to save yourself A LOT of time in future.
I went to a fantastic workshop with Emily Campbell at InVision’s Design Exchange conference last year on this topic: Design Systems for People.
She used the perfect analogy of design components to Lego to explain how established patterns and rules govern the way new things are designed.
Creating a perfect system of blocks and patterns not only helps the designer create consistent designs, but also helps the end user recognise common patterns to make it easier to navigate
… or build cool Lego stuff ;)
Here endeth the first (5) lessons. I have 5 more key learnings, so sit tight for those and please let me know your thoughts on the above! I’d love to hear your learnings and takeaways from enterprise application design, too.
