/
1
2
3
4
·
·
·
·
StatUS Console
PURPOSE
Personalization Builder users need a robust tool to be able to check whether implementation of Collect Tracking Code was successful or something is not functioning as expected. The existing status modal was very basic and users need more details such as the number of errors as well as understanding the ramifications of those errors. Originally the Product Manager asked to add on a few details, like time of error, to the existing Status Modal. I needed to understand the problem we were trying to solve and if the solution they were proposing was the right solution.
MY ROLE
My role was the UX lead for this project. I designed low and high fidelity prototypes. I worked closely with a UX researcher to design an end-to-end experience by using the information gathered from interviews, user walkthroughs, and other research methods. I maintained a strong relationship with key stakeholders to help define the project by understanding and communicating customer insights. I communicated often with development teams for transparency and to make sure the designs created were feasible from a technical and timeline standpoint.
PROCESS
INSPIRATION
The UX researcher and I agreed that this project was bigger than tacking on extra details to a modal. We agreed that we needed to help our users resolve errors, which the existing modal did not do. We identified the personas that would be using this product, a developer persona and a marketer persona. I quickly put together a prototype of what was asked and we conducted user walkthroughs with our services team and developers to see what was lacking. We also interviewed developers to understand how they would like the errors to be presented and how they would expect troubleshooting assistance.
IDEATION
We were right. Adding a couple of details was not enough. To determine the user flow, we did some whiteboarding and sketching. Developers wanted a high-level view of all the code types and the status, if it was erroring or not. Then they wanted to dive in deeper if the code was erroring. We created a flow based on our conversations with developers.
Another big thing we pushed was surfacing this tool so it was easily accessed from the Personalization Builder navigation. Currently, the modal was buried deep in the product. Only power users would know how to access this information. This product was going to solve a big customer pain point and it deserved to be it's own product as well as a place on the navigation.
Based on our findings, I was able to map out a user flow of how a user would go from implementation to using the product. This helped me make sure what I was designing supported the user flows.
IMPLEMENTATION
Using the Salesforce Lightning Design System, I built a prototype that displayed the new flow and the visual studio. Sketch and InvisionApp were used. Adopting the SLDS was a win in many ways, we were still using an older framework and needed to update the UI so it felt cohesive to the other Salesforce products but the table component used in the SLDS was cleaner, had more breathing room, which contributed to data being easily read.
Once the prototype was ready, we conducted user walkthroughs with participants to:
confirm the use cases for when the users need to access the Health Monitoring tool
confirm that our newly developed screens support the flow of how the users perform the error triage and resolution
discover the needs in instructional/informational/help messaging as well as notifications and the frequency.
The new designs were perceived very well from our participants. We iterated the prototype and did another round of user walkthroughs before signing off on the design.
Where the current status modal lives... The "View Implementation Status" link is buried in the bottom, it's easy to miss.
"Items Received" was not clear to our users. We swapped out "items received" to a 7 day trend sparkline. If users recognize a dip in the sparkline, they can see that something is not working properly.
Mark as Resolved - User can mark an issue as resolved. Once issue is marked as resolved, the issue will not be displayed as an error. They may view the resolved issues by using the filter.
CONCLUSION
From this project, I learned that...
1. Surface important tools. If an important screen takes multiple clicks to get to, you're not doing it right!
2. Provide content and help -- displaying the status is not enough, user appreciate when you go the extra step and provide clear steps on how to troubleshoot errors. Also provide links for support if the steps aren't enough!
3. Use clear terminology and find other ways to show a complicated data
4. Update users on errors and allow them to configure how they want to be notified.