/
1
2
3
4
·
·
·
·
StatUS Console
PURPOSE
Personalization Builder users require a comprehensive tool to verify the successful implementation of the Collect Tracking Code or to diagnose any issues that may arise. The Collect Tracking Code enables Personalization Builder to collect data on users and their behaviors, facilitating the creation of personalized recommendations for both web and email platforms. The status modal lacked detail, and users needed more insights, including the number of errors and the implications of those errors. Initially, the Product Manager requested additional information, such as the time of error, to be integrated into the existing Status Modal. It was essential to clarify the problem we aimed to address and to determine whether the proposed solution was indeed appropriate.
MY ROLE
As the UX lead for this project, I was responsible for creating both low and high fidelity prototypes. I collaborated closely with a UX researcher to craft a comprehensive end-to-end experience, utilizing insights derived from interviews, user walkthroughs, and various research methods. I fostered strong relationships with key stakeholders to help shape the project, ensuring that customer insights were clearly understood and communicated. Regular communication with development teams was maintained to ensure transparency and to confirm that the designs were technically feasible and aligned with the project timeline.
PROCESS
INSPIRATION
The UX researcher and I realized that this project extended beyond merely adding extra features to a modal. It was imperative to assist users with resolving errors, an area where the existing modal fell short. We pinpointed the primary personas who would interact with the product: a developer persona and a marketer persona. I swiftly assembled a prototype and conducted user walkthroughs with our services team and developers to identify gaps in the current design. We also interviewed developers to gather their insights on error presentation and their expectations for troubleshooting support.
IDEATION
Our suspicions were correct; simply adding details was insufficient. To define the user flow, we engaged in whiteboarding and sketching exercises. Developers expressed a desire for a comprehensive overview of all code types and their respective statuses, indicating whether they contained errors. Furthermore, they wanted the ability to delve deeper when issues occurred. We devised a flowchart based on insights gathered from these discussions.
Another significant change we advocated for was making this tool more prominent within the Personalization Builder navigation. Previously, the modal was obscured within the product, accessible only to power users. This tool addressed a critical customer pain point, warranting its own dedicated place in the navigation menu.
From our findings, I constructed a user flow illustrating how users would transition from implementation to utilizing the product. This mapping ensured that my design aligned with the established user flows.
IMPLEMENTATION
Using the Salesforce Lightning Design System, a prototype was developed showcasing the new flow and visual studio utilizing Sketch and InvisionApp. The adoption of SLDS proved beneficial in various aspects; it replaced an outdated framework, ensuring the UI aligned with other Salesforce products. The table component in SLDS presented a cleaner design with more spacing, enhancing data readability.
Upon finalizing the prototype, user walkthroughs were conducted with participants to:
Validate the use cases for accessing the Health Monitoring tool
Ensure the newly developed screens facilitated the user flow for error triage and resolution
Identify needs for instructional, informational, and help messaging, along with notification frequency
Participants responded positively to the new designs. The prototype underwent further iterations, followed by another round of user walkthroughs, prior to final approval of 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.
LEARNINGS
From this project, I learned that:
Essential tools should be easily accessible. If reaching a significant feature requires several clicks, it’s inefficient.
It's crucial to offer comprehensive support—just showing the status isn't sufficient. Users value having clear instructions for troubleshooting errors, and it's beneficial to include links to additional support if needed.
Clear terminology is important, and finding alternative ways to present complex data can enhance user understanding.
Keeping users informed about errors is vital, and offering options for how they wish to receive notifications can improve their experience.