5 MORE lessons in internal product design: devices & platforms, critiques, end-user involvement, building a common language and product onboarding
This is the continued story from 5 lessons I’ve learned from designing internal products at THE ICONIC. As a quick intro, as well as some great customer products & features, I’ve been designing internal enterprise products to scale and grow THE ICONIC over the past 2 years.
I’d like to 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.
1. Think about future platforms and device access
An early mistake while designing an internal application was starting with desktop-only. The decision was made for reasons. The users were a mix of permanent and casual photography studio-based employees, who use a desktop monitor to view the application. It was designed to scan product samples in and out of a location to track and manage the digital asset production workflow. We had no mobile developer allocated for this project and were under a tight deadline to release a Minimum Viable Product (MVP).
Correct decision from a platform focus — there was no logical sense in spending time designing for a mobile or iPad application that would never be built or used, however the problem remained. What happens when we migrate entirely from RF scanners to mobile scanning devices? Not on the horizon, no, but it’s better to plan for the future strategically rather than hope that your designs will translate across different screen sizes and formats.
I had designed the app to work with the RF scanners as the data input source (instead of the keyboard or mouse click) to dynamically appear on screen. Imagine you’re scanning a barcode — the input you see on screen is a sequence of letters & numbers that would be a real pain to type out or copy paste. Easy decision, but what happens when the future happens, and those classic RF guns get a device upgrade?
Simply put, what I SHOULD have done is mock up the designs in mobile artboards first (we usually go worst-case scenario 320x 568px — iPhone SE is the best phone ever made), then use that architecture as a template onto which we could build the desktop web experience. What you’ll end up with if not, is trying to design the mobile web or app experience retrospectively, within the confines of the desktop designs and information architecture. Which is a horrible place to be.
The lesson here is, ALWAYS mobile first, even in internal product aka desktop land and yes, even if there’s no imaginable future for a different device. It’s best practise for a reason!
2. Plan design critiques thoughtfully — how to get meaningful feedback on designs for a system or process your critics have never seen before
A fantastic and well-established part of our design process at THE ICONIC is to hold a structured design critique at any stage of a project. From designing the research plan, the survey or interview plan, all the way through wireframes and sketches to hi-fi prototypes. We’re all hands on deck to critique where critique is needed. We help guide the best solution to the problem that designer is sparring with.
This is one of my favourite parts of the process, not to mention where I learn the most and get exposed to different perspectives and ways of looking at a problem.
The added complexity for internal product design is how the heck to cram in all that context to help the critics understand what problem you’re solving for and why. We all have the shared understanding of the main site & app, we know what THE ICONIC is, what we sell and who our customers are.
With every problem we need a detailed introduction including the research already conducted that has led to this work and what the desired outcome is. But what if that problem space is so far outside the periphery of the room, that you need a whole meeting just to describe the current process?
Plan, plan, plan; simplify your HMW (how might we) or problem statement, then simplify it again, until it makes sense to your parents.
True advice! OK, to anyone outside the business and who doesn’t work in tech. If they can understand what on earth you’re talking about and what you’re trying to do — you’re there! Start with the business goals (brief summary), then the user problem, then build on the context and/or constraints as you go through the critique. Not too much at once! Start simple then invite questions and provide further context during the course of the design review as required.
Also, don’t be afraid to invite your participants to do some short reading / look through some introductory infrastructure diagrams prior to the critique. They’re dedicating their valuable time in helping you get to the best solution, so both sides are invested in getting the most out of the time you allocated.
Set the participants up for what’s to come so they can get in the right mindset and thinking space to help you effectively in the critique.
3. Stick with your users! Involve the end-users THROUGHOUT the design process
The design process for internal product involves input & participation from 5 key groups (I love the number 5). Your squad (dedicated tech project team— engineers, PO, data human, UXD); end users; key stakeholders (e.g. managers of your end users) tech leads; and executive sponsors. This means you’re managing and balancing priorities from each of these groups all the time!
Your job as the Product Designer is to be the voice of the user, and to speak it loudly and clearly.
Often during the research & discovery phase, you’ll unearth problems these key groups may not be aware of, which inevitably add time to a project and push out deadlines.
It’s an important and careful exercise, as with any project, to balance the user needs with business goals, tech or management constraints, and time. It is natural and expected to receive design inputs from all directions during the project.
Your expertise comes in to play here to listen, acknowledge and document all feedback and suggestions, no matter where they come from. Have a clear stance and plan on how you want to move this project forward and why.
Be open and humble, but be clear and tenacious. Be ready and equipped to have productive conversations about your design decisions and differentiate between must-haves and nice-to-haves, according to the user needs that you’ve defined.
You are representing the user, so your interpretation of the problem and how this could be solved through thoughtful, simple design is your superpower here. Stick to the user’s needs as your source of truth for decision making. A great tool for this is creating personas to focus the conversation on real user problems and quotes. This helps to materialise the hard work you’ve done to deep-dive into the user’s world and understand what’s going on.
4. Create a common language to unify your design with code
Getting a little more technical, it’s important to work closely with engineers to agree on naming conventions you’ll use to build the codebase for your designs. Why the heck? Because you need a common language that is understood and functional both in the code and the UI, as the two need to match to make sense to the end user.
By carefully unifying design and engineering behind a commonly understood naming system, you not only make it easier to communicate the product infrastructure design, but you also speed up the process of implementing the designs.
Let’s take the generic example of naming ‘pants’. When searching for ‘pants’ online — a user from the US would expect to see very different results from a user searching the same in the UK. I.e. in old Blighty, pants = underwear. However in the US and Australia, pants = trousers. (You guys are weird).
Therefore, it’s vital to define a common meaning of the word ‘pants’, or it may affect all the actions around it. I’m British, so in my design documents, I might refer to pants as underwear, but an Aussie developer will interpret that as trousers — thus with no common language, we have an awkward, incongruous outcome! And a very confused user!
This is a very obvious example for the sake of illustrating this concept, but the idea is in fact very simple.
Work with your engineers in defining and understanding the naming system, then use this to name components and layers in your design files to be consistent with that system.
You’ll avoid misinterpretations, duplicate code, refactoring nightmares and bad UX! Happy days!
5. Plan and document a product training manual & onboarding session with users
As I mentioned before in the previous article, we are often tasked with introducing new processes and workflows to the user in internal product design. Therefore a clear and succinct user manual and in-person user training session is key to the long-term success of the app.
Start by creating some hype about your product, plan a launch party and invite all the end users and stakeholders to bring them on the journey you’ve just been on to create this product.
Work with your squad to create a user training manual including a step by step guide, troubleshooting tips and how to raise issues if they encounter them. Refer to this and back to the beginning of the design journey to tell the story of this application, why and how it was designed how it is, and what future iterations may look like.
Highlight the user involvement and testing sessions to remind them how important their input was to the final product, and reiterate that their ongoing feedback is vital in making it better, keeping it ship-shape and working as well as it could be.
Not only does this create excitement and buy-in among users, but it builds more trust and ensures that they are equipped to use the tool effectively. They pass that knowledge on to others and know how to escalate future bugs and problems. Also, you can actually throw a launch party with cake and sweets and things.. what’s not to love!?
So there we have it, part 2 of my top learnings and lessons in internal product design, so far! Please do share your own stories and learnings in the comments below. I’d love to know what other tools and tactics are being used in the industry and how we can learn from each other.
To conclude, a final and important lesson is to be your own cheerleader.
Firstly, this is still pretty new, so we’re still working hard to spread the word of the importance & value of investing in design in internal product. The fact is, it keeps the business’ wheels turning and helps earn the bucks just as much as customer-facing features.
Don’t wait for the opportunity to educate the business on internal product work and its impact, just do it!
Secondly, as your products are used internally among various departments, they simply won’t be seen as much as a shiny new feature on the app. Customer product is seen, used and praised by your peers and executives, whereas the reality of working in internal product is that it’s largely in the shadows.
The best thing you can do is be diligent in gathering data and metrics before and after your app launches, as the numbers can speak for themselves to demonstrate the value delivered.
Persevere! Working in this space pushes your limits, forces you to learn hard and fast, and is a true test of your resilience.
Unlike customer-facing product, your users are your peers too; you work with them every day and they rely on you to not only make their working lives easier, but also to hit their own department goals & KPIs and those of the business. You’re all racing to the finish line together, which is an awesome, exhausting, and REWARDING challenge.
