Streamlining workflows in DNA sequencing procedures.
DNA sequencing is a complicated proccess that must follow strict Standard Operating Procedures (SOPs) outlined by OICR. These SOPs are usually menial tasks that can be partially automated and streamlined. Dimsum is a collection of similar internal tools that expedite these SOPs through responsive and highly available user interfaces.
During my 16 week internship, I designed and implemented a responsive UI for the first phase of Dimsum: Quality Control (QC) approval. I also conducted user interviews for the second phase: Project Tracking. Tools I used include Figma, Typescript, Spring Boot, and Tailwind CSS. During the development proccess, I worked closely with my supervisor Dillan on both the frontend and backend API.
Researchers performing Quality Control (QC) approval and Task Tracking need to query and compare data from sources which are difficult to access. Time and energy is being put into a task that can be partially automated and streamlined.
Create high level dashboard to present all information in one place to reduce the need to reference multiple systems at once:
I was eager to get straight to work, so I began to create some logo designs and rough mocks of tables:
But after this initial sprint, I realized that I had no idea how to continue forward! Even though I there was already a design brief and problem definition in place, I didn't have any guilding design principles to build off of. I was trying to build a skyscraper with no foundation. I decided to go back a step and identifiy my priorities.
At its core, I needed to design and code a tool to simplify and group data for more efficient research. I took this axiom and came up with two principles to design for:
Only add UI components that increases learnability, efficiency, memorability and satisfaction.
Frontend development is hard, and I need to allot enough time for it during my internship. A simple design is better than none.
After these two principles were defined, I set out to explore design paradigms that would be simple to implement while also efficient.
The more information and options a site has, the longer it takes users to make decisions. Sounds like common sense, but it's something thats often overlooked. However, users still need granular information and high-fidelity tools (i.e. numerous sorting & filter options) for their work. Stripping all of that away makes the entire project useless.
Then, how can a site be simplified while offering still granularity?
If you can't remove anymore UI features, you have to create the illusion of simplicity. There's many different apporaches, but here's three:
PD introduces users to a system with a few select, overarching options that expand to a larger specialized set of data upon request. A few examples include hamburger menus and dropdown options.
With PD, the very fact that a component is made visible establishes that it is important. This creates a guilding hiearchy for novice users. For advanced users, reducing visual clutter means less time spent scanning options before making a decision. Thus, PD ticks all the boxes for use in Dimsum
Humans have a limited working memory of only around 5-9 pieces of information. However, this limit can be stretched by categorizing information into "chunks", and memorizing these "chunks" instead. Consider this example:
While a sequence of 10 numbers is hard to memorize by itself, the task becomes a lot easier when its grouped into chunks of 3's and 4's found in phone numbers. Suddenly, 10 pieces of information is reduced to only 3 digestable chunks. This reinforces the illusion of similicity while increasing memorability and learnability.
The key takeaway here isn't to confine yourself within the 7 ± 2 limits of working memory, but rather to use categorization to as another way to create an illusion of simplicity.
Negativity bias, second order effects and familarity bias are just some of the many cognitive biases that are out there. When adding and changing UI elements, it might help to run through this list to double check against any negative side effects.
With a better foundation of research and design principles, I began fleshing out the design system of Dimsum. My first goal was to establish typograpy and colors:
Sarabun was used in a variety of other internal tools, so the decision was made to continue using it in symbolic areas for Dimsum. Inter is a simple and clean sans-serif font that lends well to body text. Both were open source and easy to access under Google Fonts, so it also made implementation much easier.
A minimal color pallete was choosen with a few primary grays and status colors. I also added an accent green that pairs well with the existing OICR branding.
An obvious area to start were the filters and pagination. Dimsum has a huge amount of them that I organized into a collection of dropdowns:
Filters are organized by overarching categories which users can click into to see more options. Submenus were also organized into categorizes with dividers in between.
Dimsum's dashboard consists of multiple tables, not just one. Initial mockups had them stacked vertically on top of each other, but that just lead to super long pages and alot of scrolling fatigue. This was a area where progressive disclosure had alot of potential. I introduced a tab bar on the top of the page that switches between different tables on click:
Displaying all detailed information for a single table cell would introduce uncessary clutter that goes against established design principles. Tooltips were used to metigate this:
By not constraining the design to any pre-existing JS tooltip libraries, we had full control over the information presented and its formatting.
Our work is open source! Feel free to take a look at the codebase here.
Dimsum was a unqiue challenge to implement for OICR as it had its own unique design system and a set of custom components. There were challengeing questions to be asked when it came to deciding the frontend stack. Dillan and I wanted to use pre-built libraries wheneever possible to reduce developemnt time. Unfortunately, there weren't any affordable table libraries that had the features that we needed. Building up the initial framework ourselves took 2-3 weeks.
When it came to styling, pre-built component libraries also lacked the customization that we needed. I happened to stumble upon Tailwind. Rather than managing large semantic stylsheets, Tailwind offers a set of "utility classes" which lets you directly style from the HTML. No single paradigm is better than the other, but for Dimsum it had some key advantages:
Adam Wathan (Tailwind's main dev) wrote a great article on utiliy-based styling that you can read here.
Unexpected techincal challenges always come up during development. Though most were solved with little to no changes to the design, dropdown menus had to be reworked because of positioning issues realted with the submenus. Rather than having secondary menus that appeard on hover, the new design used a "two-staged" set of dropdowns that behaves almost like a setup wizard:
This behavior still complies with the principles of PD by hiding more detailed information in a second stage only visible when prompted by the user.
I came into Dimsum with the expectation that I could start creating wireframes straightaway. It's only when I completely lost direction that I realized I forgot about the first half of the double diamond proccess.
Through this project I actually realized I quite enjoy research and ideation. There's alot more critical thinking that heavily influences the rest of the proccess. If a solid foundation is built, the rest of the project becomes much easier.
For future projects, I'll aim to spend more time researching and defining project principles in order to streamline the design proccess as much as possible.
Dimsum contained alot of custom elements and componentry that couldn't use libraries. While we didn't have much a choice for many of them, some didn't need to be fully customized to be effective. Other times we forewent (google tells me this is a real word) using frameworks because of the difficult learning curve.
As an example, Dillan and I decided to vanilla TypeScript instead of React or any other JS Framework since we both had little experience with them. While this was fine at first, managing best practices became really difficult as the codebase grew. Some UI components were implemented as classes using an OOP apporach, while others were functions that used a functional paradigm. Though a framework locks you into certain practices, I think having that consistency is much more valuable.