Bloomcast—Monitoring shellfish safety in Washington state 

As the largest producer of shellfish in the nation, the Washington State Department of Health (DoH) maintains a Shellfish Safety Program (SSP) that exists to monitor and report the harmful levels of marine biotoxins in a variety of shellfish species. Potentially lethal if consumed, it is imperative that reporting levels of these toxins be both timely and accurate. 

Through rigorous field research, our team identified a number of processes, tasks and systems that could be greatly improved. Our design response was a hybrid CRM / IMS web application that leveraged existing systems to automate common communication tasks and lessen the workload of the SSP team, all while being cognisant of organizational and technical limitations. 

Research

The majority of our time working on this project was spent on research. To familiarize ourselves with the process of how shellfish biotoxins are measured, tracked and communicated, we shadowed a number of team members who are also, of course, subject-matter experts.

The design process was highly collaborative—we regularly met with the team to review our designs and assumptions. 

Field Observation

The first phase of our research was travelling to a monitoring site. There, we were guided through the process of collecting sample shellfish and transporting them to a lab for testing. To our surprise, we learned that these samples are often shipped through UPS or at times even transported by Greyhound bus.

In-office Observation / Workflow Walkthrough

Next, we were invited to the Shellfish Safety Program office to observe a typical workday. Our first surprise was in the amount of printed contact lists, spreadsheets and misc. documents, many adorned with a number of post-it notes. 

Another important finding was the number of software programs and databases regularly used. All of them seemed to rely on eachother. Yet none of them had the capacity to communicate with another. Methods for communicating harvest site closures were quite varied—including email, phone calls, text messages, bulletins and even faxes. These two observations in particular would later become design principles.

Given the nature of the work, SSP employees spend around half of their time out of the office, travelling along the Puget Sound to collect samples. We heard a number of complaints about the inability to do their job while without cell coverage from team members. 

Perhaps the biggest surprise of all, we learned that one particular employee retained a wealth of information in memory. Other employees relied heavily on his knowledge in order to perform their jobs. Luckily, he hadn’t taken a sick day in years. Still, we thought getting some of that info out of his brain and into a computer would be a good idea.

Lab Tour

The last phase of research was a tour of the W.R. Giedt Public Health Laboratory, the sole location for testing for biotoxins in shellfish in the Washingtong state. Guided through rooms of highly sophisticated and specialized scientific instruments, we were immediately surprised by the contrasting technology for recording these instruments’ results—hand on paper. Red pen for bad, black for good. From here, these hand-written documents were passed on to a lab technician who then manually input the results into the lab’s own software. Finally, a spreadsheet is exported and sent to the Shellfish Safety Program office. They then print the spreadsheet and input results into their software. Yeah... I know.

Identifying Recurring Complaints and Shared Pain Points

A number of issues were mentioned quite often. The difficulty in collaborating and communicating while out of the office was expressed almost universally, as was performing redundant work. Additionally, I had taken note of a number of processes that would be trivial to automate. 

Mapping the Flow of Information

Once we had distilled feedback to a core set of issues, it became apparrent that we needed a better understanding of the flow of information among team members and their regular tasks. After a few rounds of review, this flow chart helped us narrow the focus of what design response would be best. And as we were to present our findings to the board of directors, we decided a “best-bang-for-your-buck” approach was appropriate.

Research Insights (RI) to Inform Design Opportunities (DO)

(RI) Unpredictability is inherent
(DO) Automate / eliminate unnecessary tasks and streamline time-intensive tasks

(RI) Managing relationships is critical
(DO) Facilitate communications and communication provenance

(RI) Out-of-office-work is mandatory
(DO) Device agnosticism

(RI) Antiquated technology tethers people to the office
(DO) Design for mobile devices, allow input sans cell coverage

(RI) Urgency leads to workload fluctuations
(DO) Enable preparatory work to smooth workload timelines

(RI) Human error happens
(DO) Automate where possible, provide logs for automated tasks

Design

Ideation

We had a pretty good idea of what type of design response would be best at this point. Entirely replacing isolated databases and software systems currently in place, while needed, was not likely. So we proposed a new, device-agnostic, web-based application that leveraged currently existing systems.

In order to show stakeholders and the Board of Directors how this tool would increase employee efficiency by simplifying and automating tasks, we storyboarded a potential usage scenario. Since the users of this tool were often traveling, we regularly discussed how features would vary on desktop vs mobile.

Sketching 

The storyboard was very well received. We then sketched a few simple dashboards. We were still working under many assumptions at this point so we deciced to keep functionality fairly general. This was immensely helpful in identifying useful features, as well as solidifying information architecture and process flows.

Establishing Visual Design

As this was a group project—and as the deadline was soon approaching—we needed to jump straight from hand sketches to a more polished UI. The first step was establishing the visual brand to ensure each of us were working with consistent UI elements.

Medium-fidelity Design

After feedback on our lo-fi sketches, we simplified interactions and implemented more of the visual brand to our mockups. We then imported these screens to Flinto to test a number of interactions.

High Fidelity Design

To our surprise, the client approved the mid-fis as done. They were very happy with the functionality and requested to see only a few pages as hi-fi. 

Outcome

The Shellfish Safety Program works by the seat of their pants. When a few hours can mean the difference between toxic shellfish being shipped to market, urgency is a given. Recalls are messy, unreliable and thus best avoided. However, this urgency is somewhat predictable as weekly routines are fairly consistent for the SSP.

The core purpose of this tool is to smooth out fluctuations in SSP workload. This is done in two essential ways—automate tasks where possible and enable a greater degree of prepatory work to be completed during periods of relative calm. 

In presenting this project to the board of directors, we focused mainly on five ways that this tool would increase both accuracy and efficiency. 

(1) Automation: Nearly a quarter to a third of the workday was spent on tedious / trivial tasks. Implementing these automations would pay for itself in a matter of weeks.

(2) Redundancy: With team members almost always in different locations, many tasks were being done more than once. Allowing team members to see what others were working on would prevent this.

(3) Preparation: A great degree of the SSP’s work could be done in advance. Team members mentioned Tuesday as an especially hectic day of the week. We identified a number of tasks that could be done in advance, lessing the workload spike during this time of the week.

(4) Mobility: Current systems were either desktop- or even device-bound. Often times travelling team members would have to call the office just to have someone look up something. Queries to these databases need not be tethered to a particular location.

(5) Accuracy & Recordkeeping: Many tasks were being done by hand—pen and paper. Not only does this greaten the potential for human error, it also leaves no accurate records. We were sensitive to employee hesitation in digitalizing these tasks but once we showed a few scenarios, they were completely on board. 

Workflow Before & After 

In order to concretize these five points, we concluded our presentation with a “before-and-after” flow chart.