Rethinking Help for Enterprise
3 min read
3 min read
In the summer of 2018, I joined the AppDynamics Design Technologies team under the direction of Brian Zaik and Eric Wienke. We were a small, but rapidly growing, design team for a suite of products that serves multiple Fortune 500 companies.
When I joined the team, we were focusing on building out our internal design system, codenamed Particle.
(Release date TBD)
I was working independently to define the future of in-app help for the suite of AppDynamics products, working on answering the question of—
What can we do when an user is confused / frustrated within the app?
Given that I came in with a rudimentary understanding of AppDynamics’s suite of enterprise products (APM, EUM, etc), I spent the first week getting up to speed and understanding—
• What are our products and how do they work?• What is the structure of the company and how does the organization work?
After that, I dived deep into understanding how in-app help currently manifests itself within the platform — first figuring out the scope of help implementations and then figuring out what problems each component is working to solve.
Here, I found it was essential to develop a deeper understanding of the entire suite of products given the breadth of where and when in-app help exists.
Altogether, I discovered 14 different components of in-app help with an average of 2.6 different implementations of each. Yikes.
Further complexifying the project was the existence of other teams which have done pre-existing work to solve the same problem statements through different means. While it was awesome to brainstorm with them, that did mean that there were more cooks in the kitchen.
To be successful, we can’t compete with each other, but rather we should augment each other’s work to create an ecosystem of products and features that best serve our customer’s needs.
As such, my first step was to identify who was leading all of those platforms and check in with the current thoughts surrounding those projects and make sure everyone was aligned.
Given my lack of experience with complex enterprise products, I wanted to make sure I had a broad swath of product interactions to draw inspiration from before moving forward. As such, I spent two days throughly researching our competitors (Dynatrace, CE) as well as other complex enterprise products (Azure, Confluence, AWS).
The next logical step was to talk to our customers to see what they thought about our current implementations of in-app help.
To my surprise, there was no internal processes in place for making it easy for the average designer to interface with users so I started off interviewing internal stakeholders, who have directly worked with our users and have synthesized their pain points, while acknowledging their biases.
Concurrently, I spent time looking for users through a variety of mediums with mixed results. This was surprisingly challenging and a far cry from my usual experience getting rapidly feedback for consumer products. Furthermore, it was more difficult as I wanted to find new users to our products, those that are less familiar with our platform and would need more support.
From these sessions, and their subsequent synthesis, I was able to create lower level problem statements that helped me align myself towards the goal, as well as the other internal stakeholders.
Alignment is hard in a larger company — a far cry from the startup environment which I was used to.
After working with our user research team and a fun few rounds of synthesis, we were able to create hash up some basic user personas and some other synthesis docs to work off of. Too much information has always led to paralysis for me so I tried my best to distill insights into their first principles.
The goal was to develop a product-agnostic set of components that can be combined to create a framework for in-app help to rest on in its current iteration as well its future potential iterations that were on the product roadmap.
Okay, time for the first round of designs.
It kinda sucked.
So I put it in front of our internal design team to get feedback — they subsequently wrecked me.
Great feedback though.
After another iteration of designs, I decided to place them in front of actual users. (Once again, finding users in enterprise 🙃)
Sample v2 screenshots —
For iteration 2, I wanted to test out a new hypothesis. While I knew people generally hated the idea of “states” given the amount of cognitive overhead it entails, I thought that the design pattern might actually have a place in the bulky enterprise products.
Given the fact that such a small percentage of users interact with in-app help, it didn’t make sense for it to take up valuable real estate on the screen.
It was just a weird idea to me at the time. But weird ideas are worth testing.
These usability sessions was tricky to lead since the idea of “help”, at its essence, is context-specific and wide-ranging. If the users knowing that we were testing our implementations of in-app help, this would reflect in their decision making process and cause their behaviors to shift. Tricky tricky.
I would love to say that I found the optimal way to approach such situations but the truth of the matter is that, given the small sample size of interviews (5), I was able to make some significant learnings but not formulate a framework to use moving forward.
These feedback sessions were very helpful, as talking to the real users usually are, and led to the third, and final, iteration of my designs.
Through the initial round of user interviews, a major pain point that emerged was that there was that it was difficult for AppD users to share company-specific knowledge with their coworkers. This was especially prevalent when teams had to onboard new users onto the platform.
This was so large of an issue, that many of our Fortune 500 clients created extensive internal databases of help documentation for the AppD product. These became quickly saturated by one line notes that were hard to find. Users hated having to go through those databases. In short, there wasn't context<>information alignment.
Small companies with only 1-2 AppD users per team had it the worst. When that person would leave, the entire scope of product knowledge for that company was lost.
We needed a way to seamlessly turn that tribal knowledge into institutional knowledge.
So I brainstormed ways for users to quickly leave accessible and context-relevant information for their coworkers. That gave birth to the idea of change commits.
This feature would allow users to leave quick notes on the screen for their coworkers in just 3 clicks anytime. In certain situations, you will be prompted to leave the note right after you make an important change.
This fell right in line with the thesis derived from other teams surrounding the future personalization of the product as an extension of each user.
What do techies like? Code commits. What might AppD techies like? Change commits.
While this idea would need to be fleshed out more in order for it to be successful, early user testing has shown favorable results that validates further work on the concept.
© Albert Dong, 2018. All Rights Reserved.