One of my go-to methods of familiarizing myself with a new industry is to conduct a deep dive into secondary research, and so I started with reading articles about calibration and monitoring. However, it quickly became clear that the calibration process remained an abstract, murky topic to me. This puts the success of the project at risk.

The client and I decided to invest in an onsite lab tour so that I could learn about the hardware in a more hands-on way and chat with their lab technician about calibration. Since I'm a visual and tactile person, this was very helpful for my understanding, and further helped to build trust with the client, who could see that I was invested in internalizing their business.

As we worked together, I developed this design process:

• The client wrote a PRD (product requirements document)
• I scheduled a discussion with the client to go over the PRD together, during which I sketched and took notes
• I started to design iteratively and involved the client, lead engineer, and delivery lead in reviews
• Once finalized, I handed off designs on zeplin with annotations and a video demo on loom
• The delivery lead went through my design deliverables and used those to draft stories in Pivotal
• I reviewed the stories to make sure they accurately capture the design intent
• The lead engineer facilitated storytime, during which the engineers would identify any conflicts or missing corner cases, and then the story was ready to build

To be honest, when I inherited this project, I found the visual design lacking in aesthetics, consistency, and usability. However, I endeavored to work within the existing front-end in order to minimize scope. This proved to be more difficult as we progressed, especially since the existing styles didn’t scale well to different scenarios.

As it turned out, the client was not satisfied with the existing visual design either, so I advocated for taking a sprint off from designing new features so that I could create the foundation of an improved design system.

After front-end stories were implemented, I conducted design QA and accessibility testing. Though we have worked with this client for over a decade, accessibility was previously never integrated into the process in a holistic way. I conducted keyboard and screen reader tests, using analytics to guide my decision to use NVDA on Windows as the primary screen reader. In the review, I included resources to help explain the errors I found and how to address them.

Note - embedding accessibility into the design system and conducting continuous accessibility testing was effective. We also learned through this process that it's critical to write accessibility AC's and prioritize any accessibility issues found in testing to help the team focus. As a co-lead of the accessibility initiative, I am continuously finding ways to improve and influence our accessibility processes throughout the company.

Sophisticated customers need the ability to manage the calibration of their sensors in-house so that they can retain ownership of their system.

Dickson provides calibration as a service to their customers, which a process to ensure that the sensors are measuring data as expected (e.g. a thermometer that reads 62°F is accurate). If the sensors are not calibrated, this creates risk as the data is no longer reliable. Some larger, more technically robust customers have their own calibration resources in-house, and they would rather handle this process internally than have to rely on Dickson.

Users may have any number of sensors that need calibration, and it is possible that they are on different calibration cadences (6-month, 12-month, etc). I decided to use a wizard-like process that guides the user through the process - they start by entering information about a calibration batch, selecting sensors to include, providing data on the unit under test (the sensor they’re calibrating) and standard (the calibrated sensor they are using for comparison), finishing with a record of the batch and all changes made.

Users desire a monitoring system that fits their mental model and focuses on the thing that is being monitored (equipment) rather than a piece of hardware installed (device).

Equipment was one of the features needed to achieve feature parity with the acquired French product. Previously in DicksonOne, users would navigate through their system by devices, which are IoT endpoints that stream data from the sensors to DicksonOne. While the devices provide a more direct connection to data, our theory is that equipment is more intuitive to users.

We designed equipment so that they could represent anything from a warehouse to a room’s ambience to a refrigerator. Users have flexibility in setting up their equipment and can connect them to any number of channels. Alarms (a legacy feature) can be applied to individual channels or the equipment overall. This means that the equipment monitoring widget needs to be scalable and include multiple alerting states.

I used my colleague’s design for the mobile app (created before I joined the engagement) as inspiration for a new monitoring widget. Knowing that not all our users are technically savvy and many of them are likely in high-stress working environments (e.g. healthcare workers) I designed a more friendly UI with wider margins, larger text, and icons and colors that would pop off the screen without creating unpleasant negative space. To help guide the experience, I used the CRUD framework (create, read, update, delete) to ensure we captured an end-to-end experience.

Users desire the ability to view their equipment and devices on a floorplan so that they can more easily locate anything that’s alerting and needs immediate attention.

The floorplan was another feature needed for parity with the acquired European product. If an endpoint is alerting, it might be difficult for the user to locate exactly where it is, especially if the monitoring system is installed on a large site. Being able to display where endpoints are installed in a visual way could provide a lot of value in an emergency.

The challenge here was that DicksonOne systems were already organized by location, which have a hierarchal relationship. With the way architects often provide deliverables, floorplans sometimes encompass an entire floor with multiple rooms. We also do not prescribe what a location entails, the user could name anything a location. In order to provide the needed flexibility here, we decided that locations and floorplans would have a many-to-many relationship, meaning one location may contain multiple floorplans and one floorplan may contain multiple locations. The user may navigate to the floorplan by navigating to the location, or to a page to monitor all floorplans in their account.

I designed an image upload modal and a simple map pin for multiple different types of assets and alerting states, with an expandable tooltip that contains details about alerts. Keeping the pin design as simple as possible will help in the case that a floorplan is covered in equipment and devices. Additionally, to accommodate keyboard accessibility, I designed different interactive states (default, hover, focus, active) and annotated the focus order for the different interactive components.

Users desire the ability to create a collection of data that is relevant to a specific audience so that they can quickly assess the status of a system and respond to anything urgent.

Today, there is a dashboard on the DicksonOne homepage that has somewhat questionable value. The client is not satisfied with the dashboard and analytics suggest that users often have a different page bookmarked (often the alerts or device monitoring pages). The client was somewhat resistant to invest heavily in user research, so we decided to work off their hypothesis that users would find value in creating a custom dashboard to suit their unique needs, with the suggestion that we seek feedback from users once we introduce the feature.

There are a few different use cases for how a dashboard may be used. Users can set a custom dashboard as their homepage or set it up on a TV display onsite. They may also send the dashboard to supervisors to make high-level assessments on the system, or to help sell the value of the Dickson system to a decision-maker. It was important that we support different sharing capabilities and a variety of different screen sizes.

The thing about dashboards is that they’re often surprisingly complex, and as we brainstormed, the scope of the dashboard quickly spiraled out of control. To reign it in, I created a user flow that brings the user through navigation, creation, editing, and sharing. During the editing phase, the user may add any number of widgets from any number of monitoring points (devices, equipment, locations, and channels). For MVP, we limited the number of widget types (we excluded the floorplan, firmware updates, and calibration widgets) and limited editing (we excluded different text styles and color modes). Limiting customization while also retaining the general user flow helped ensure the MVP would still deliver a holistic experience.

At the time that I'm writing this case study, most of these features are still in the process of being implemented. However, speaking to the impact on our business, the success of my work expanded the client's understanding of the role of design on a project. This paved the way for the client to find new opportunities for us to work on, emphasizing the importance of my role on the team.