As a UX designer in the enterprise space, I find that some degree of complexity exists not only for me, but for the customers of the products I’ve worked on, as well. Even the process for a customer organization to obtain and adopt new products can be lengthy and involved, with many steps and different personas along the way. For instance, individuals making buying decisions are rarely the ones who will be using the product. And the user base itself is often further split by product administrators and end users.
So, how can we first cultivate and then continually feed an understanding of our customer’s journeys? Connecting directly with users through research is always an obvious answer and our greatest tool. But it’s not the only means available to us!
You can more quickly build toward a 360-degree view of your customer’s journey by tapping into the many customer facing teams and artifacts within your enterprise organization.
From technical marketing to technical writers, sales, and customer support, there are teams that either work on the front lines, interacting daily with users or creating content that directly influences their experiences. If your company is like VMware and has made this wealth of knowledge and resources internally accessible via field archives or other team archives, why not take advantage of it? You can leverage both artifacts and people — connect with colleagues in these roles, treating it like a user interview or benefiting from their documented insights.
I’ve worked on a couple of different products at VMware. In each case, I found that leveraging these resources accelerated my learning and helped me form a more well-rounded understanding of my users.
Customer-facing teams and artifacts live in all phases of the journey
Let’s take a look at a very high-level customer journey and explore how various customer-facing teams and artifacts plug into it. While the following is roughly based on VMware’s organizational structure, the recommendations in this post can be applied to most enterprise products/services companies.
This rich ecosystem of customer insights and influences can help you understand, assess, and fix any gaps in the overall journey.
The “learn” phase
It’s valuable to take a step back and build awareness around what exactly our companies are pitching to prospective customers. Whether it’s through various marketing channels (webinars, blogs, etc.) or pre-sales engagements, how do we position ourselves, and what key value propositions do we highlight? If you haven’t already, familiarize yourself with the messaging on your customer-facing product website. This is one of the initial touchpoints that prospects have with us and it’s important to know what we deliver in our product story.
What are prospective customers thinking?
A treasure trove of insights sits within the technical marketing and pre-sales teams. These roles are either creating content that will be consumed by prospects, or they are in the field interfacing with them directly and regularly. During conversations with pre-sales, I’ve found that they can share trends around customer perceptions during the “learn” phase, due to the volume of their customer engagements. For example: Why do customers prefer us over the competition? What are some of the tipping-point features? How often are prospects for our emerging products net-new vs. existing customers? And what are common misconceptions that prospects may have when first considering a new VMware product?
Insights from technical marketing
Technical marketing managers are the folks who write the playbooks for the field. Due to the deeply technical nature of some enterprise offerings, they relay the why/how/when to use our products. Recently, through a combination of technical marketing artifacts and user research, I was able to uncover that some portion of our customer organizations were not using key product features as designed. This was quite a disconnect. The insight I came upon was based on 1) direct conversations with users around their product behaviors and 2) knowing what we officially tout as the intended way to use our software. The latter was accelerated by digging into some of the technical marketing managers’ artifacts — namely webinars, blogs, and internal presentations. This was immensely helpful early on when I joined the team, since the core value propositions of my current product offering had been defined well before I joined.
In this example, I benefited from the knowledge of the technical marketing team. But it’s not a one-way street. It’s not only important to understand what concepts and workflows technical marketing describes as important to our end users, but as product designers, we should also partner with them. After all, their work is based on the product requirements and experience that product management and product design establish together.
The “try or buy” phase
Whether your company offers a free trial or a similar way of evaluating product benefits, this is a great place to develop a sense of how potential users try out your products.
In our case, the virtual infrastructure space is not simple, and bringing customer environments into an on-premises-based trial can be too involved for some prospects. One avenue that VMware offers instead is a program called “Hands-on-Labs.” This simulates what it’s like to use key flows and capabilities within our products. I think all designers at VMware should step through a Hands-on-Lab or two — enough to get a sense of the primary concepts, tasks, and features that users are introduced to. Imagine yourself as a new user. How might what is presented help? Are there gaps? Is there consistency with the product story that was delivered earlier in their journey? If you have similar programs in your enterprise organization, check them out.
Further insights from the field
Sometimes product evaluations are done via a more elaborate process, especially for enterprise products that may require onboarding customer data. At VMware, some customers choose to do a proof of concept (POC) with us. Solutions engineers (SEs) and architects often help with these. SEs are part of the broader field team and work alongside pre-sales as experts on the technical aspects of our solutions. It was through conversations with solutions engineers that I discovered how arduous it can be for customers to stand up POCs for the product I worked on. Apparently, these prospective organizations were required to address certain prerequisites within their virtual infrastructure environments before they could fully evaluate us using their data. This amounted to a very manual, tedious, and non-standard process. The challenges here were not due to VMware, per se, but they still delayed further evaluation. Was it possible to automate this process for our customers? (The solution wasn’t that easy, but just knowing that this problem existed and hampered product adoption was pivotal.) Knowing is half the battle!
The “use/grow” phase
This is the part of the journey that designers are typically associated with. Other groups in the company, including technical writers and customer support, can be a great help.
Help systems can be another unexpected place to find help. They meet a critical need when the user is in a pinch and needs a quick answer. Often, they are embedded in the product, within the context of a specific task or flow. “How do I do XYZ,” or “What is this concept and how will it help me?” are a couple of the questions these systems are designed to answer. As designers, we are better equipped if we learn just how easy or hard it is for users to find answers to their problems, whether in a self-service manner through in-product help, or via external help documentation. Here, again, is an opportunity to collaborate more closely with another team — the technical writers. As product designers, we share a border with them in the overall journey. Tighter integration between the two groups can produce a smoother user experience.
What isn’t working well?
As designers and researchers, we know how powerful it is to hear directly from our users. Along those lines, have you ever listened in on a customer support call? These exchanges are unique, in that customers typically only reach out when they have problems (and often with a fair degree of frustration). If the support team in your company allows for these kinds of “ride-alongs,” take advantage of them (if not, you might consider helping to establish this type of opportunity). You can also try listening to recorded calls. Whether live or recorded, you’ll get to hear the customer sentiment and how end users describe very real problems in their own words — very impactful.
The customer-support channel, along with other field teams, usually funnels issues and service requests downstream. These often end up in a backlog that makes its way to the folks who are building the products. Get ahold of this list and periodically review it with your cross-functional partners. I’ve found this provides visibility into the hottest issues. Real-world scenarios may also help build a clearer picture of the “UX debt” within your products, and referencing actual customers goes a long way when trying to prioritize fixes.
What has worked well?
It’s also important to find out what success looks like for customers. Whether through the product website or via your field organization’s artifacts, delve into some key customer case studies. Granted, case studies are intentionally written to spotlight the positive aspects of an experience. But they are still indicators of what customers and your organization consider success. What business problems have your products solved for customers — and with what features/solutions, in particular? Also, since these customers have already partnered with your organization, they may be great candidates for future research.
Putting it all into practice
None of the above is meant to replace user research. Hopefully, like at VMware, you have an amazing research team that provides guidance on conducting your own studies! But tapping into these various customer touchpoints can augment your research and give you additional perspectives. You don’t have to dig into every last channel. Just remember that these are at your disposal. You can cherry-pick/tap into the resources and teams, based on your immediate needs.
Key steps you can take:
1. Know where to go in advance. Familiarize yourself with some of the resource repositories these teams I’ve mentioned have (if they’re public). Then you can dig into relevant artifacts when the need arises.
2. Form initial relationships. Connect with some of the folks from various teams mentioned here. It’s good to have contacts for when you find you need more information down the road.
3. Actively partner. Find opportunities to collaborate with some of the teams that are closer to your phase of the journey (such as technical writers and technical marketing managers). This can unearth opportunities to collectively improve upon the user experience.
Part of our job as product designers is to design experiences that are tied to business value. The additional perspectives you can gain from these customer touchpoints will only buoy those efforts. So check out a customer-facing webinar, a sales PowerPoint deck, or chat with a field person over coffee. Just like you, these individuals are responsible for our customers’ journeys, either through their direct interactions or by crafting content and experiences along the way. And most likely, they will learn something from you, too!