Students are excellent teachers

Things I’ve learned about enterprise design while teaching it

An iridescent rendering of an apple, in front of a mirror, and its reflection on a violet background.

Illustration by Marco Mueller

In the early days of personal computing, software was often clunky, slow, and inconsistently designed between platforms. Today a product, service, or even a physical experience will be deemed second rate if it’s not carefully considered and well designed.

The same expectation applies to enterprise products.

I’m an enterprise product designer at Adobe working on Adobe Analytics, a tool that enables marketing organizations to analyze data from anywhere in the customer journey, and I’ve been challenged and excited by this space since the beginning of my career. Why? Because I find the problems incredibly complex and unfamiliar. But also because the users of enterprise software have been largely underserved when it comes to good design.

In fact, I think that good design for enterprise is so important that I also teach an undergraduate design course in the Multi-Disciplinary Design program at the University of Utah where my goal is to educate students on the realities of working as enterprise design professionals… without crushing any dreams they have of designing the next viral app.

Teaching has been an incredible exercise in personal growth; it has forced me to hold a mirror up to my own design methodologies and urged me to question old design practices. I do my best to teach reusable design practices that scale to any type of product design and observing how students have interpreted my lessons has taught me some things about enterprise design.

First, a couple of definitions:

Enterprise products are software, services, and applications used by large organizations that enable their employees to create better customer experiences, and manage, manipulate, analyze, and store large amounts of data.

Enterprise design, the design of enterprise products, involves solving problems (usually distilling large amounts of complex information into flexible, easy-to-use workflows) for the organization’s employees who rely on the products to do their jobs.

Efficiency and simplicity are innovative

The difference between enterprise and consumer products can be summed up by the types of jobs users are trying to accomplish with them. Enterprise products are used to perform jobs, whereas many consumer products supplement jobs or tasks. For example, an accountant at a retail company might use an enterprise product to run payroll and might also use a food delivery app to grocery shop. Using a payroll system at work is a requirement to get a job done while having groceries delivered via an app is optional.

Another key differentiator is that enterprise products often support multiple tasks while consumer-based products might only support a few. As an example, a consumer product like a messaging platform might offer more leeway for a designer to create interesting animation s or different patterns of navigation. This is because the act of messaging is well defined—most people understand how to select a contact, type a message, and hit send—and users are tolerant to some variety in how the platform is designed. But with an enterprise product a user might be trying to complete ten different tasks, none of which are well defined or have comparable workflows in other applications. Because users are simultaneously trying to understand a task and how to complete it in the interface, it is best to design workflows that meet expectations and resist the temptation to change navigation patterns or add sound effects.

Teaching has been an incredible exercise in personal growth; it has forced me to hold a mirror up to my own design methodologies and urged me to question old design practices.

The way we create innovation in enterprise design isn’t by distracting users, but by providing innovative workflows that support them in the tasks they need to complete. We provide smart defaults so that users can select from suggested items instead of having to conjure inputs from scratch; we guide users through set-up with a scalable first-time experience so that they understand how to get started using the product; and we use progressive disclosure methods to allow users to complete only the necessary tasks in a workflow without feeling overwhelmed.

Learning to trust ambiguity

One thing I see with every new class: Students want to get to designing screens before they even know why they are designing them. I can feel my class’s discomfort as we sit in the discovery phase, not knowing what the end-product is going to look like. (I’ve felt this same unease going through this phase with our product partners, which usually includes product managers and engineers.) No one likes not knowing how big the project might be, how long it might take, or how many customers it might appease. But it’s our job as designers to trust that the design process will uncover the right problem to solve.

One way we establish trust in the early stages of the design process is to define very clear user goals and use them as our north star. Finding the right problem to solve can be hard but knowing what users should accomplish or how they should feel makes the process of discovery less overwhelming.

In class I recently changed a project prompt from “solve a problem that x-users are having” to “solve a problem for x-users that makes them feel more successful at their jobs.” My students overflowed with ideas. At work, this same approach helps us begin designing a solution and helps our product partners (who aren't designers) feel confident that the discovery process is chipping away at a larger initiative that will guide users to success.

The most impressive artifact is not always the right artifact

The actual users of enterprise design products are often not the people who purchase them. It's common in large organizations for teams in charge of budgeting to work with senior leadership to decide which tools the company will invest in. When doing user research it’s important to differentiate between “customers” and “users” and to understand how these two groups interact. To do this, we document the relationships our users have with other people in their organization as well as the other products and services they use in parallel with our tools.

To replicate this process in class we create experience maps to document the start-to-finish- steps in a user’s journey. Anyone who has ever created these artifacts knows how incredibly time-consuming they are to create and how overwhelming they can be to interpret.

Experience maps show complex relationships complexly, highlighting multiple problems the user is having—for which there could be multiple solutions. So, unless you’re presenting every solution for each friction point, showing a full experience map can detract from the actual solution you’re presenting.

No one likes not knowing how big the project might be, how long it might take, or how many customers it might appease. But it’s our job as designers to trust that the design process will uncover the right problem to solve.

Don’t get me wrong, they are good alignment tools which is why I still teach them. But it took me noticing how my students would gloss over presenting their experience maps, and instead show other visuals that represented their research, to realize that the maps are better at representing a full picture of a user’s journey rather than highlighting the logic behind a particular design direction.

Lean into ignorance

My students do more thorough research when they are trying to solve problems they know nothing about. Why is this? Because when you know nothing about a topic you are forced to learn it, instead of relying on personal life experiences.

When you don’t know your users well enough there’s a danger of designing based on personal bias. When you think you have gained enough empathy for your users, you run the risk of overgeneralizing their needs.

I fell victim to this thinking early in my career when I designed entirely based on user archetypes or personas; I thought since I'd created those artifacts I knew enough about my user’s wants and needs. Now, I am always looking to find the sweet spot: being aware of the types of problems users face, but not so confident in my knowledge that I assume I know how they would want to solve them. It’s why I always encourage my students to practice learning and designing in tandem and to share their work, with users, early and often for feedback.

Enterprise product design is a team sport

I’ve seen my students create great hypothetical projects when they have full (individual) creative control over them. But the reality, especially in enterprise design, is that you will never be the only person influencing the user experience. In fact, you will likely be working on a team of ten or more people from various departments (including sales, marketing, product management and engineering). And many of the members of those teams will have started building relationships with your users even before those users have logged in to the product to see the experiences that you, the UX designer, have created.

The bottom line is that the “user experience” begins long before a user opens an app.

To ensure we’re designing a cohesive experience it’s important for us to know and understand the relationships and experiences that users have with other teams. Collaboration with our partners in product management, engineering, sales, and marketing, is incredibly important because they have expertise that we as designers must rely on to better understand problems. If, for example, I can understand the marketing team’s goals, and speak in the language they use to communicate them, I can better communicate how my work is affected by or will influence their goals.

Great designers create experiences that also help their partners achieve their goals.

In class, I bring in representatives from each discipline to guest lecture about the goals of their departments and how they view working with designers so my students can begin to understand that being a great designer isn’t just about mastering the craft of design. It also helps my students understand that while they control the entire user experience while creating hypothetical projects in school, in the working world they will have to design with more requirements that result from relationships other teams may have already formed with users.

My hope is that they realize something I’ve also learned from teaching them: Great designers create experiences that also help their partners achieve their goals.

If you haven’t read anything else, read this

As an adjunct professor, and a product designer working at Adobe, my goal is to teach in a way that represents what being a design professional is actually like today, whether or not my students choose a design occupation. And the reality is that due to the development of new technology, the role of ethics in design, and the high expectations of our users, the design profession is changing rapidly, which makes the responsibility of teaching the “correct” thing feel scary.

When I started teaching this course, I was terrified. I still regularly second guess whether I am qualified enough to educate students about how to be great designers when I am still in the process of becoming one myself. But teaching has helped me develop my own skills and better understand my passion for enterprise design. Complex problem solving, a hard-working and appreciative user base, and collaborating with other product teams are just a few of the reasons I advocate for more designers to consider the enterprise space.

From my students I have been reminded to always be willing to unlearn things, to be wrong, and to let someone with less experience or “expertise” teach me something. Really, we are all just students and the more we bring the willingness to learn into our professional lives the greater designers we will become.

Header copy
Design your career at Adobe.
Button copy
View all jobs
Button link