Build great enterprise tools, 9 UX tips
By Olga Shevchenko, Senior User Experience Designer at The Financial Times
Designing, developing and delivering internal products from scratch can be challenging for several reasons. Your team might receive too many requirements from stakeholders, and you’d need to consider how to build a user-friendly product and deliver on a business goal or your users might be scattered globally having different processes and tools in place that manifests in different user needs and user journeys. If you are designing, developing or responsible for the success of a new enterprise product, here are 9 practical tips to navigate the challenges this may bring.
Tip 1: Start with the basics — consider your users.
First of all, figure out who your users are. Sometimes, a user and a stakeholder is the same person, sometimes your stakeholders manage your users and sometimes your users are the real customers of your company. If your user and a stakeholder is the same person, feel free to set up usability testing sessions with them, as well as workshops, for collecting business requirements. If your stakeholders manage your users, you might receive a list of business requirements from them and uncover unexpected challenges from users conducting user research activities. The needs of senior stakeholders (who potentially fund the project) and managers might be very different from the needs of users who will work with the tool on a daily basis. To be able to deliver a tool that satisfies the needs of both groups and delivers a certain business outcome, it is crucial to walk your stakeholders through the summary of insights and prepare your proposed solutions to issues that have been raised by users. Building a great digital product alone might not solve all the problems, and keeping unanimous understanding of business process and business jargon among users aligned with the user experience of the product is essential for the success of the initiative, your team and your company.
You need to know if you are building a product for 5, 20 or 100 people and whether your users are located in the same building with you or they are scattered globally. Knowing how many users you’ve got gives a better ability to decide what feedback to take on board. If you only have 5 users, getting similar comments from 3 people is ample. But if you get similar feedback from 3 people and you’ve collected feedback from 100 users, that makes it a less valid case when trying to get your product prioritised. Another aspect that will be affected by the amount of users is creating ‘personas’. A persona, from user research perspective, is a created character that represents an audience segment and is based on the motivations, habits and preferences of the real users. If your product is mature, the personas should be based on various types of qualitative and quantitative research. Personas help teams to better understand who they are building products for. It is more likely that a product used by 5 people will have only one persona but if you’ve got 100 users, you are more likely to have at least 3 personas. Working with remote teams might bring additional challenges for usability testing sessions and quality of the feedback. If you are showing a prototype to someone who is based on another continent, ask them to share the screen with you first and then send the link to the prototype. Kindly explain that you need to see where your participant clicks as it will give you an insight you are looking for.
It goes without saying that internal products should follow the minimum accessibility standards but you need to find out if your users have any particular type of disability and adjust accordingly. One of the conditions that will affect designs of your tools is colour blindness. The Colour Blind Awareness organisation sheds light on the numbers: colour blindness affects approximately 1 in 12 men (8%) and 1 in 200 women (0.05%) in the world.
You can use Stark plugin for Sketch or Chrome extension A11Y — Color blindness empathy test to better understand how your designs will work for different conditions of colour blindness. Although these tools might not emulate conditions with the accuracy of 100%, they will give you a good idea what works and what doesn’t.
Another condition that will affect user experience of your products is motor disability. There might be users who may not be able to use the mouse at all or may have limited ability to control the mouse or the keyboard. Also consider if your users will be using voice-activated software.
Tip 2: Understand and collaborate with your own team
Teams that build enterprise tools for their colleagues might not have any experience working with a UX designer or user research team. Be prepared to explain what you do and what the benefits of robust user experience are for the business and users. Organise the sessions with the team to share the insights from user research, ask your team members to help you taking notes so they can see how it works first hand. The best comment I’ve got from an engineer on the team was: “I initially thought that the product was invented by the product manager and has no practical use. But now I understand why we are building it”.
Alignment inside the team plays a vital part. The process that works very well for one of my teams is the following: Every Monday a business analyst, a product owner and a product designer catch up for 30 minutes to discuss our priorities for the next week; on Tuesday a tech lead, a business analyst, a product manager and a product designer catch up for a 30 minute pre-planning session to go through the tickets that need to be put forward into the planning session on Thursday; on Thursday the whole team has an hour long planning session to go through the tickets and discuss them in more detail. The team can challenge any ticket and if there are not enough details, it will not be moved into ‘To Do’ list. Without pre-planning this session in the past we would spend 30 minutes discussing just one ticket, simply because we couldn’t agree on priorities. You can think: “Oh, it sounds like a mini waterfall process!”, and you might be right but there are no right or wrong answers when it comes to what process would work best with the talent you have in your own team.
Tip 3: Build relationships with your stakeholders and users
If you are building a product for the global team, consider time difference and arrange meetings or usability testing session at a time which is convenient for your colleagues. Sometimes you’d need to have a call at 7 am or at 7 pm but nothing builds the connections better than respecting the working hours of your colleagues.
Consider the culture of the team you’re building the products for. What are they like? What hours do they work? What equipment do they use? What are their essential tools? How is their day structured?
The benefit of designing internal tools is that you know your users by name and can say ‘Hello’ when you see them in the office.
Your stakeholders might have never worked with a UX specialist before too so invite them to the meetings where you talk about user research and demo your work in progress. Try to get involved in the meetings that your stakeholders have with each other, and clearly communicate that you will be there only to observe, to get a better context for your project and to hear their feedback, ideas and thoughts.
Tip 4: Follow a user-centred design process
It doesn’t matter if you are designing a boutique product for a small group of people or millions of users, there is always a question: “Are we solving the right problem?” User research might uncover the gaps in the process which can’t be solved simply by building a new tool. In this case, escalate the issue to senior management. It may be that these user problems can’t be solved through technology alone and business processes or team practices might be better candidates for change. In my experience, regular surveys, usability testing sessions, card sorting and contextual inquiry activities work best but, of course, you might need a completely different set of methodologies depending on your audience, product and timelines.
Tip 5: Think twice about copy
How you label the UI components, blocks of information and calls to action is crucial for a robust enterprise product experience. Are your users native English speakers? Is English their second or third language? Are they foreign language speakers or second language speakers? Foreign language speakers occasionally use English for business, while second language speakers are more likely to live in an English speaking country and use it daily. The difference is massive as native English speakers might pay more attention to copy and labels while second and foreign language speakers might be less picky about the labels but read and understand them literally without being able to freely interpret based on the meaning. In one of our usability testing sessions we’ve had a prototype with an experience of assigning a stakeholder to the account. This part of the experience was at the bottom of the page under the label called ‘Contacts’ and the empty state just had a plus icon without any label. Additionally, above this section there were several checkboxes with the word ‘stakeholder’ in one of them. The task was spelled out as “Please show me how you would assign a stakeholder to the account’. Native English speakers easily found the section with the contacts and proceeded with the tasks, while participants with English as a foreign language were looking for a word ‘stakeholder’ on the page and were scrolling up and down the page several times trying to interact with the wrong part of the experience. Needless to say, we’ve changed the label to ‘Stakeholder contacts’ and changed the confusing copy in the section above making the experience 100% clear.
Tip 6: Build responsive tools
The majority of users access internal tools on desktop, and some teams don’t have laptops or are reluctant to use the company’s internal digital products on their personal devices. Consider the functionality of the tool being easily translated into mobile without massive dev effort. I wouldn’t call it mobile-first approach in design, but definitely mobile-friendly. Your users might use the tools you are designing on the commute, while travelling abroad or during the meeting. In this example, you can see that the functionality of the checkpoints is identical both on mobile and desktop, apart from a small tweak in the size of the buttons on mobile.
It is simply cheaper to build the tools responsive as it cuts down the cost of development, and you will have a competitive advantage over other enterprise product solutions which are provided off-the-shelf but do not behave responsively.
Tip 7: Surprise and delight users
Traditionally, enterprise tools look very functional and dry as historically they have been built with a minimum design effort. Business-oriented tools for slicing data and producing various reports are rarely built with the intent to look and behave in a ‘fun’ way. It is great to see that Salesforce introduced animations with the bear in their Lightning UI and other tools like Monday.com and Asana have some amusing animations bringing more personality to their products.
Who said the internal products need to be boring? You or a member of your team can design small delightful interactions which will not distract the users from performing their tasks or create fun illustrations to mitigate experiences in cases of getting an error. Your users probably browse other digital products and apps in their free time and have seen products with great UX.
Tip 8: Consider the whole ecosystem
The product you are working on is very likely not the only one your users utilise on a daily basis. There are at least 5 other digital products they have on their laptops and phones for a professional use (Google docs, email clients, calendars, messaging apps, HR portal), if not more. Think about what user journeys are like when your users interact with several products and switch between them. How about integration with other internal systems? Would it be beneficial to the users if your new product deep links to other off-the-shelf products?
If you have Salesforce as your main enterprise system for the sales teams and you have a couple of internal tools, how valuable it would be that all the systems ‘talk’ to each other?
Tip 9: Refer back to the purpose of the initiative
When trying to balance different requirements, think about the purpose. What is your team trying to achieve by delivering a tool? What is the purpose of it? What is the mission of your team? Why do you all keep coming back to work and keep doing what you are good at?
A mission of my team reads “The Internal Products Team helps the FT to work smarter and better serve our customers”, and this is what I keep in mind when I talk to users, design experiences or participate in discussions.
While designing and building internal tools you will have plenty of input, and it might be overwhelming. Stakeholders, users, your team, your UX peers. The main takeaway is when you are getting feedback or insights that contradict each other, bring it back to your team and collectively try to answer a question: “What is the right thing to build to solve the problem?”
