I came to enterprise software recently joining IBM design. Before this move I worked on mostly consumer facing applications at two startups and two agencies. A lot of my peers questioned my move. Their experiences with enterprise software companies were often loaded with organizational challenges that greatly slowed or even blocked progress. While I have found some truth in their feedback, I have also had some success with navigating around some common obstacles in these environments. Here are four approaches I have used to tackling key issues with enterprise UX design.
1. Accessing actual users
Enterprise software companies tend to have enterprise clients. So, the relationships are between businesses or B2B. Most of our meetings I have with clients tend to be with a sales representative from my company and decision maker on the client side. A lot of the information exchanged does not come directly from the people using our product.
Possible approach: Leave the office
Those meetings with sales and decision makers are still necessary for letting the client know we are actively working to improve the experience. However, we cannot entirely rely on them to drive our design decision. You should be narrowing down who would use your product. In our case at IBM Bluemix, we are focusing on developers who need to get an app onto the cloud. So, we invested time to go to coworking spaces where developers from other companies could test our work.
2. Shipping organizational silos
Designers, who come from smaller organizations or straight out of school, will most likely experience some culture shock with navigating cultural norms of large enterprise companies. Teams are not always in the same location. Schedules and deadlines are often not aligned to the same sprint schedule. Leadership hierarchy and team organization also can cut across logical sections of the product. As a result, the experience shipped to the market might reflect the logic of the company organization and not what the user expects.
Possible approach: Come together to coordinate
While there are considerable barriers to solving this issue, designers can at least start to bridge gaps. One reoccurring story I hear from designers in enterprise is that of duplicate efforts. Here is a common example that I have found. Three separate teams working on a solution for how to get started in the product. The drive came from three different product owners who report to three different VP’s.
Designers can start regular check-ins to learn more about the work from other teams and when it is going to be released. The next step is to coordinate how these solutions can come together. When do the teams plan on releasing this initiative? How do they work to solve a common problem for the product? Does any of their work interfere with any other team?
3. Addressing technical and design debt
If the product better reflects a company organization chart than a logical experience for the user, then it has technical and design debt. Product teams are under pressure to meet a release schedule. Design, development, and product management often make concessions to meet those deadlines. From a design perspective, some of these concessions amount to an experience that is less cohesive. If not addressed in a timely manner, these suboptimal experiences add up, and the user will view the product experience as broken.
Possible approach: Document and prioritize eliminating debt
This is a conversation that should take place regularly. Designers should document the concessions made in previous releases. For each check-in, demo day, and product presentation, refer back to the list of list of technical and design debt that current work addresses.
The key is to find people who will be your champion. Find those higher up who care and prove to them that you are worth their investment.
4. Fear of taking risks
Shipping org charts and accumulating technical and design debt can come from a company culture that punishes risk taking. It is a fine line that leadership has to draw with pushing innovation and satisfying profit margins. I find what often gets communicated down to the teams is a reluctance to take chances for the sake of the user. Fears of immediate ramifications tend to overshadow the reward of driving towards the long term vision.
Possible approach: Find champions for vision
The key is to find people who will be your champion. Find those higher up who care and prove to them that you are worth their investment. You will need to build their trust with your work. You will also need to pitch the vision for the product and the risks they will need to take.