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. 

bloomcast_banner-tg-web

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.

sample-collecting-tg-web
sample-shipping-tg-web
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.

office-paper-tg-web
office-screens-tg-web
office-paper-highlighter-tg-web
office-science-tg-web
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.

lab-equipment-tg-web
lab-sheet-tg-web
lab-setup-tg-web
lab-software-input-tg-web

Research Synthesis

At this point, we had a accumulated a wealth of research. We knew that a comprehensive, “one size fits all” design response would not be feasible. Rather, we decided to narrow our focus and address actionable issues within organizational and technical constraints. The team had mentioned that they would like us to present our design response to their board of directors so feasibility was placed at the forefront.

Research Synthesis

At this point, we had a accumulated a wealth of research. We knew that a comprehensive, “one size fits all” design response would not be feasible. Rather, we decided to narrow our focus and address actionable issues within organizational and technical constraints. The team had mentioned that they would like us to present our design response to their board of directors so feasibility was placed at the forefront.

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. 

research-synthesis-tg-web
observationcards-tg-web
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.

flowmap1-tg-web
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.

scenario-1-tg-web
scenario-3-tg-web
scenario-2-tg-web
scenario-4-tg-web
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.

hand-sketch-1-tg-web
hand-sketch-3-tg-web
hand-sketch-2-tg-web
hand-sketch-4-tg-web
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.

visual-brand-tg-web
bloomcast-logo-tg-web
Low-fidelity Design

Still honing in on most useful features and functionality, we refined our use case scenario with low-fi mockups.

Low-fidelity Design

Still honing in on most useful features and functionality, we refined our use case scenario with low-fi mockups.

protocol-flow2-tg-web
protocol-flow5-tg-web
protocol-flow3-tg-web
protocol-flow6-tg-web
protocol-flow4-tg-web
protocol-flow7-tg-web
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.

mid-fi1-tg-web
mid-fi3-tg-web
mid-fi2-tg-web
mid-fi4-tg-web
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. 

hi-fi1-tg-web
hi-fi2-tg-web
hi-fi3-tg-web
Mobile Envisioning Addendum

While initially out of the project’s scope, we found ourselves with a few extra days for this project. Initially, the client said that tablets and PCs would be the devices most fitting for the tool. However, we noticed that communication via mobile phone was a large part of the job. Unbeknownst to the client, we did an envisioning exercise as to how a companion mobile-only app could increase the tools efficacy.

The primary purpose of this companion app is communication provenance—who has received communication, when did contact occur, by what method and by whom. Plus, it was a chance for me to sneak in some data viz.

Mobile Envisioning Addendum

While initially out of the project's scope, we found ourselves with a few extra days for this project. Initially, the client said that tablets and PCs would be the devices most fitting for the tool. However, we noticed that communication via mobile phone was a large part of the job. Unbeknownst to the client, we did an envisioning exercise as to how a companion mobile-only app could increase the tools efficacy.

The primary purpose of this companion app is communication provenance—who has received communication, when did contact occur, by what method and by whom. Plus, it was a chance for me to sneak in some data viz.

phone1-tg-web
phone2-tg-web
phone3-tg-web
phone4-tg-web
phone7-tg-web
phone6-tg-web

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.

flowmap2-tg-web

More Projects

Shellfish SafetyResearch / IxD / VCD / Process

Scatter Plots in VRResearch / Data Vis / Dev / VR

CORE-MIIxD / Dev / Research / Process

ECHRdbData Vis / IxD / VCD / Research

Outsourcing PollutionResearch / Data Vis / VCD / Poster

US-China FDIData Vis / IxD / Dev