Mike's Notes
An article I found on LinkedIn.
Resources
References
Repository
- Home > Ajabbi Research > Library >
-
Home > Handbook >
Last Updated
18/05/2025
Breaking down enterprise UX design
By: Stuart Silverstein
UX Collective: 23/04/2020
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.
