Mike's Notes
An article I found on LinkedIn.
Resources
References
- Reference
Repository
- Home > Ajabbi Research > Library >
- Home > Handbook >
Last Updated
18/05/2025
Breaking down enterprise UX design
Enterprise Applications, the discipline of Enterprise UX, and where the differences are between Enterprise and Consumer and how to approach the complexity.
Customer care team
The term “Enterprise UX” is a hot term. It returns about 53 million results on Google now. The fact is, that after many years of working on Consumer applications, businesses are starting to see the ROI that companies achieve by investing in the internal applications that their employees use to conduct business.
I remember asking a former boss about whether a tool was an “Enterprise class” application, and her response was “Enterprise class just means ugly and hard to use.” While I laughed at her response, the hard truth is at the time, she was right.
While that was back in 2012, many Enterprise applications are still ugly and hard to use, because of the complexity, the age of the applications, lack of global perspective, and ad hoc requests. Historically, Enterprise implementations have been disjointed and cluttered, and hard to use, in addition to the “ugly” factor, which not only contributes to an increase in “eyesores” (MY EYES!!!!), but also cause legibility, scanning and comprehension mistakes that are often more costly to fix than to get right. As a result there has been a renaissance in Enterprise UX with several companies doing an awesome job of creating great Enterprise design, such as Salesforce, Intuit, and Microsoft.
These applications are often very process and business rule heavy, and often require a ton of flexibility and customization features. This is typically in contrast to a typical “Consumer” app, where consumers expect to have a simple intuitive experience for the lions share of the features. This means the Consumer side applications are skewed toward the first use, not the 1,000th, whereas he Enterprise app needs to be prioritized for repetitive use, and geared towards a user who will inevitably be a subject matter expert, well versed in prioritizing their workflow and understanding of the application architecture for goal completion.
In addition, Enterprise applications will almost always have a Service Design component. A person uses the software in the service of his/her job in order to accomplish a specific task with which the technology assists.
Some examples:
- A Customer Service rep needs to access orders in order to see where the order is at, and then needs to place a note on the order for the production team.
- An Inventory Management team is managing the inventory and communicating with the order team when products run out.
- Sales team member needs to track sales, follow up with leads, and keep track of his pipeline.
- A Project Manager needs to see what tasks are assigned, who is working on what, communication on the tasks, and the progress towards completion.
These are all services, where the technology facilitates views of the status and data within the system, notifies people within the system of jobs to be done, and automates some of the work—essentially, monitoring, data entry and reporting functions for the end user.
Another part of the applications are the large data sets. Enterprise applications are often working with 10x the amount of data that a customer actually sees. For example, a customer might see their name, address, telephone, email as part of their record, whereby the users of the Enterprise system can see those basic demographics in addition to clicks, pages visited, lifetime value, projected sales, etc. The customer needs very little information in comparison to the Enterprise user, plus Enterprise users need to be able to see and manipulate all the data behind the scenes. Also, when they cannot fix the issue themselves, they need an efficient way to let a team member know what to do… at scale.
These data sets, typically housed in a central database, are pooled from multiple applications within the platform. Within this data, as an Enterprise UX designer, we are tasked with making sense of all of this for the various user groups. There are various data objects (User, Order, Item, Communications, etc) with relationships to one another. A Customer may be the central object in our system, but has contact information, email communication, sales, etc, which are attached to that customer object.
Each of the objects come with “attributes” — such as address, city, state, cell phone, etc — that have historically been developed and formatted to match the business rules and system architecture, versus the humans at the end of that data. As a result, it is up to the designer, to make sense of all the business data, and make sense of it back to a user, in an organization that makes sense to them, and displayed at a time in their flow that they need it. Without clarified relationships of objects, applications can become messy very quickly. With the advent of big data, and systems that are able to house every click and interaction, the amount of data we have becomes very daunting to the average human to digest.
Plus, an Enterprise worker has 10x the amount of functions that a consumer app has, and has to integrate toolset, processes and information seamlessly. The result can be very complex and hard to use to the best of users — leading to poor job satisfaction, increased error rates, and lost efficiency and productivity at the very least—if not well thought through and executed. At the worst, it can cripple organizations from scaling their business.
As a result, organizations are now taking the user experience of internal applications very seriously and applying traditionally consumer focused methodologies, such as a user centered design approach to determine feature/function priority and look and feel.
What skills do you need to design for Enterprise Apps?
For sake of argument in this article set, I am going to assume you know how to do “Consumer UX design”— you understand how to research and identify needs, create prototypes to test, and develop thorough solutions for development. There are several great treatises on those subjects, so I will avoid them.
These skills will be foundational to the techniques discussed further. If you are not familiar with design, development and research, I would start there. This is definitely an advanced topic, as it builds on foundational UX domain knowledge — in addition to the fundamentals of User Experience design.
An Enterprise UX designer will need deeper competency in:
1) Interactive Design/Prototyping (including Research and Analysis)
2) Information Architecture
3) Service Design, Ecosystem and Service Blueprinting
4) Business Rules and Requirements or working with a Business Analyst (BA) if you have one.
While number 1 and 2 are part of a UX designer’s T-shape toolkit, 3 & 4 may require some additional experience. Even if you have experience in all 4, there will be some new ways you will need to figure out how to use them together. The interaction design will be much more complex, prototyping state based prototypes with inputs that pass data and variables, telling a story in your prototype in order to test it. This means Invision, Principle, Figma, Sketch etc may be insufficient for handling the job alone, if those are your primary tools.
I‘ve done Enterprise projects in Invision that have over hundred screens for a singular flow and if someone made a mistake, I had to reset the test and I think hurts feedback without the input data and variables to see where users get hung up on inputting information. In my experience, there are better tools for collecting usability feedback (aside from a concept test—which I will get to in upcoming articles).
In addition, these apps can require an advanced grasp on Information Architecture. This does not mean simply the organization of articles and content, but also organizing the data objects and attributes. In order to visualize how all this data works together, it will be helpful to make concept models of how all the data objects relate to one another. Then you can put them back together in a way that makes sense for the tasks and the user group. This is often one of the critical steps in organizing information in a way that makes sense and is digestible. Once you have a concept of how objects relate, you can make sure it aligns with the users and their needs. By making sense of the data objects in a model, it becomes easier to reconstruct them according to the users mental model.
In terms of Service Design, being able to visualize services in operations flows to see how the application will help to see how the technology integrates with the service. User Journeys work in a very similar fashion to Service Blueprints, however, a User Journey is for one user and through the lens of the user and the Service Blueprint is through the lens of the organization. This allows us to understand the needs of the system and make it work for more efficiently, not just the singular user. When working at the organization level, seeing how the whole service comes together, helps you better understand all the requirements, and the effect of your design decisions, and how the different user types might use the same flow.
System flow
This leads to point number 4 which is being able to document these business requirements visually in enough detail to design a solution. Most projects I have been on have a Business System Analyst (BA or BSA) on your project. You will both be working together on this, but the BA will be the owner of the requirements, and your tightest collaborator, working on features and analysis of the system.
Designing Flexibly vs Tailor Made:
Modules can be placed in multiple places
Often when we are designing for a consumer flow, we design a tailor made solution for a particular group, anticipating every need. When you get into Enterprise, you need to think flexibly because the amount of work it will take to create unique solutions for every user group. In addition, if you are working on a SAAS or cloud product, you need to accommodate for all different types of implementations and customizations that each organization will want to make. Different people need different permission levels within a product necessitating varying access to functions in an application. In addition, the flow of tasks is often fluid and changing, and often in different order. Systems like Microsoft Fluent Design System and Salesforce Lightning are designed flexibly to be used in any context and can be applied by an administrator without dev help.
Designing modules and components that can work in multiple contexts, will make it easier to add and manage the module in the system. For instance, a communication module — which shows all the emails, texts and communication with a customer — may be used at a customer level, an order level or a user level. Developing flexible modules decreases level of effort, and increases reusability and consistency. Modules in an Enterprise system typically take a bit longer to develop in Enterprise due to the complex nature, so if you make it as reusable as possible, it will save time and development effort in the long run, just like any design system.
The challenge then becomes figuring out where in a nonlinear flow a user may need entry into the particular task they are trying to satisfy. I like to think of it like the difference between a categorical taxonomy and a tag system. A categorical taxonomy implies that an item lives in one place, and is organized by drilling down to the item. A tag based taxonomy implies that an item has multiple facets and can be accessed from multiple avenues. Think more like “tags,” less like “categories.”
So we think of quick micro tasks that make up a larger task, and add entry points. For instance, if a customer service rep is looking up a customer name, looking at their history, reading notes, and then creating a ticket and sending an inquiry. This is all one “task,” but there are several “micro tasks” that you can evaluate a design for one by one once you have identified where the issue lies.
Access to the micro tasks are key. You may have the same button multiple times in various places, and it is cluttering and duplicating the action, and you may be right. But in Enterprise apps, due to the multiple entry points might make sense to approach it this way even if it does seem like duplication. Users in Enterprise apps often need to be able to enter a workflow from various points because their workflows are variable.
Different types of Enterprise applications
With all of this “Enterprise” information, there are different types of Enterprise projects, and they all have different needs. If you are working on a SAAS or cloud application, it will be implemented by a company, and thus will need a great deal of flexibility in implementation. An internal CRM will have a 360 view of a customer linking to other internal systems to all the central data.
As a common thread, we will stick with the definition of:
“A complex piece of software with lots of data, various distinct user groups, and several non-linear complex tasks that workers use to get work done.”
This covers all types of Enterprise applications, both internal and 3rd party. SAAS and Cloud products, CRM’s, Enterprise platforms, Analytics packages, Accounting Software, Email programs, and the like. As a result, there are set “classifications” that the average Enterprise will have.
While this is no means an exhaustive list, these are some of standard ones I have run across in my travels. Many of these apps are platforms that cover multiple categories, however, for this exercise, I have simplified them based on function and main class of the application. This is a mix of SMB and Enterprise Apps. For simplification, I am including both, because the SMB apps are usually more “consumer like” and can provide inspiration for a better experience.
These applications may be:
• Internal : Applications developed internally
• Purchased : Purchased software or SAAS product
• Customized : Off-the-shelf apps which have a different or modified
presentation layer.
• Combination : part Purchased, part Customized, part Internal
Examples of typical classes of Enterprise applications:
CRM (Customer relationship manager) — houses all information on a customer, primarily used by Sales and Customer Care teams to understand customer context and history. Typically in integrated with communication, ticketing, reporting and/or marketing platforms.
Examples: Pipedrive, Sugar CRM, Insightly, FreshSales
CRM application screens
CRM apps Pipedrive, Insightly, and Freshsales. All have some sort of customer page, a pipeline and reporting capabilities and integrate with other systems.
ERP (Enterprise Relationship Program) : These are large complex platforms that incorporate elements of all the different applications into a singular suite in order to customize an implementation and have all the pieces integrated. Modern ERP’s have a complete set of modules and a design patterns, which you can leverage to create solutions quickly.
Examples: Microsoft Dynamics, Salesforce Lightning, NetSuite, Zoho, SAP
CMS (Content Management Systems) : A system for publishing content or creating HTML pages or emails. typically used by content and marketing teams to publish content on the web, applications and social media.
Examples: SharePoint, Drupal, WordPress
Calendar and Scheduling : Apps that show you when events are, and often the ability to schedule one or multiple people.
Examples: Calendly, Time Trade, GCal
Analytics/Reporting : These apps can be Sales, Behavior Tracking, Reporting or visualizing any type of data. They are typically used by the entire organization, but will have different views depending on the user type — For example a view for the product team with details, and a view for Executives with less.
Examples: Tableau, Google Analytics
Productivity Suite : These apps are very straightforward — the swiss army knife that allows any user to create content for work — Word docs, Spreadsheets, etc. Typically integrates with communication for sharing.
Examples: Office 365, Airtable, G-Suite
Accounting/Invoicing : These applications are for keeping track of sales and orders. There are typically more specialized software the Accounting team will use to keep track of sales and money, especially for tax purposes, but this can be used by all parties to track the details of a sale.
Examples: Xero, Quickbooks, NetSuite, Acumatica
Support/Ticketing : These are for tracking defects in a system. This can be a Support application — whereby Customer Care Reps enter tickets to keep track of customer errors, or a bug reporting system, and/or tech support. They often have “cases” or tickets as a central object in their system, which are issues that need resolution, which are assigned to people to solve.
Examples: Zendesk, Jira
E-Commerce : Applications that allow companies to create inventory, sell products and often run reports. May also integrate with a POS system.
Examples: Magento, SAP Hybris, Shopify
Intranet/Wiki : Applications that companies use as a hub for all employees to find other team members, communicate with others, find out policies and benefits and access other software.
Examples: Sharepoint, Confluence, Igloo
POS (Point of Sale): Think of this as a complex cash register. Employees at a physical location ring up items — can be food or retail purchases — and then take payment.
Examples: Swift POS, SquareUp, Vend
Communication : These apps are to communicate internally or externally and have many different forms — chat, email, messaging, etc. They all have some sort of “thread” and someone is able to send a message and notify another user of the message where that user can send a response.
Examples: Slack, Email, Text, Facebook Messenger, LiveChat, Intercom
Project Management : A list of tasks and status of a “project.” This can mean anything. When I worked in the Real Estate space, and we considered a home sale a “project” — whereby you had documents that needed to be completed within a period of time, and we needed to track the progress towards done. If it has tasks, deadlines, scheduling, and a goal — it’s a project.
Examples: Asana, Wrike, Monday, Microsoft Project, Trello
Automation: These applications can be anything whereby the user creates an automation, and then is able to monitor and get reporting on the system. This can be a marketing automation or a process automation or data transfer. If you can create a custom flow and have the computer do all the work then it is an automation software project.
Examples: ServiceNow, Salesforce Marketing Cloud, Autopilot
System Monitoring: These are software that lets a person see how a system is behaving in order for them to make adjustments. This could be an airplane cockpit, a heartbeat monitor, a supply chain management or a telephony app. The idea is to let the human at the end see what is happening, and if there is a problem to make it known.
Specialty Apps: A specialty app is used by a specific group, for a very specific task. While specialty apps may combine a few of the above into a specific context, the difference here is that it is typically for a very technical specific audience, which has little or no need to communicate the details to the rest of the company. Think of your design software falling into this category. While there are ways to “export” the designs to be consumed, Photoshop is definitely geared toward the designer to get work done.
As you can see, these applications are combined together to create an “experience” and workflow for a worker. A sales person might use the CRM to keep track of his/her leads and sales, but will use a Reporting modules to see sales and Communication modules to email information. On top of that, a salesperson is also doing these things in tandem to try and accomplish something bigger than the individual task. Furthermore, the salesperson is not going to get a specific “sales” CRM (although they do exist).
Each of those teams will have several people doing very different things with the data. A Customer Care rep will look at the customer information only to validate an identity and then look at orders, whereas a Salesperson will want to see when the customer’s birthday is in order to send a surprise. As thus, you often have several different groups which need to use the same application, often with different needs. However, we need a singular app or platform with views that accommodate each particular user need to mold to the task at the right time.
We need to balance the organization of information, action buttons, and pacing to match the needs of the user.
Another critical piece of information on these software pieces, is that often they are not purchased by the people who use them. So, if you are using a SAAS software the app needs to “look impressive” for the purchaser, and perform impressive to keep the team happy. The SAAS software also comes with the challenge of needing to be customizable for various types of users, which means that customization on these types of projects will be key, for sales, support and performance of the software.
Integration and the evaluation of the whole experience.
Now, the challenge becomes distilling this down to something digestible, but there is one more topic to cover: Integration. With Enterprise applications in particular, there needs to be integration points and consideration of the whole experience. As stated above, the Enterprise applications are very rarely used in isolation for a specific task, and more often than not are used in tandem.
Think about the Salesperson example above. We need to not only consider the application we are working on, but also how the network effect limits or prohibits productivity as a whole. If I am creating new orders, and my order system and my CRM are not connected, then I have segregated data, but I also duplicate the work by reentering the contact information. We want to be able to look at the entire experience to see how the tools interact with one another, so as not to create work silos that tank productivity and extensibility of the data.
When we are thinking of evaluation methods, we will want to be able to create artifacts to review the following in order to evaluate the experience:
1) User Journey and Context
- User Flow
- User Journey with error correction plans
2) Service Design and Operations Flow
- Service Blueprint
- Service Blueprint to show service and flow across the organization
3) Data Objects, Application Ecosystems and Relationships
- Concept Model
- Data concept model to demonstrate relationships of data objects
4) Task Analysis and Opportunities for consolidation
- Task analysis
- Task analysis across user groups
5) UI Flows and Usability
- UI Flow
- UI Flow for micro-task
- UI screen
Break the experience down to the level of zoom
1) Organization/System level — The highest levels of the software. This will involve understanding all the different user groups at a high level, task analysis and prioritization across all user groups, and data analysis of high level objects.
2) User Level — This level involves breaking down a specific problem into its tasks, and understanding the issues that affect productivity. While you will need to understand data objects, in this case, they are typically a smaller set, and be able to organize the attribute level to organize the information. The journey of that particular flow and where there are problems within that journey are of greatest interest to pinpoint for deeper investigation, as well as the service pipeline that might affect your design.
3) Task/UI level: Analysis at these levels occur when there is an application that is up and running well, but needs to be fine tunes. This is going to be actual usability testing for a flow, combined with contextual understanding and interviews with the user(s).
Levels of Zoom : Organization, System, User, Task, UI
These levels are cumulative, and in order to get to UI level or execution level details, you will need to work your way down. For example, I was on a project, and my creative brief from my boss was “Salesforce… take a look at it.” Seeing as her request was very broad, and had very little detail, I had to start at the organization level, and work my way down, by starting with identifying the issues that were the biggest across all the user groups, then finding out which of the tasks needed to be improved. After that I was able to tackle the UI pieces that I was responsible for myself in execution. To get from organization to UI takes a few rounds of refinement, but due to the complexity of the system, it helps break it into digestible chunks.
When you are approaching a system, if it is too big to digest in one round of work, you will need to break it down. You need to get down to the tasks or goals for you to solve first before you can solve. This can be a little different than Consumer level design, whereby the tasks are often simpler and linear, and you are usually solving for less complex user types and needs. Enterprise apps typically have lots of business rules, and complex user types doing lots of different functions, and it takes time to understand those, and decide where to start, therefore, the approach really should be multi-level.
In my experience of working on an internal applications and customized applications in particular, I have often walked into an organization where systems has been devoid of UX for a long time — which means the system needs to be analyzed starting the organization level and worked down to UI. The Enterprise product and tech teams were fielding requests, and collecting business requirements, and problem solving with the business owner directly. This typically means “add this button here so I can do x while I am on this screen.”
As of 2018 survey by UX Pin of 3,157 UX, Product and Engineers, only 26% of teams have had a UX practice for more than 5 years. In this same survey, the no 1 problem teams were working on was consistency. This can be due to the historic nature of other disciplines owning UX in pieces, but not looking at the entire experience.
Enterprise software can be an exciting new challenge for those designing consumer apps who are looking for new challenges. Hopefully, this article has given you a place to start when you have to get a handle on a large app, and form a plan of attack on approach.
