Deploit

Overview

Deploit is a web-based tool, saving time for bioinformaticians, researchers and biologists every day. It's is an intelligent compute platform for genomic data analysis which is cloud platform-agnostic and allows users to reduce analysis times and costs by up to 80%.

The Problem

Long story short: at the moment it’s possible to sequence a human genome within less than 4 hours and it will cost likely less than a that human’s phone. Just to compare, first human genome sequencing cost $100.000.000 (one hundred million dollars). The drop in price and time allows for generating larger amounts of data. Raw data doesn’t make much sense, it’s needed to be processed, or analysed. To do that, special scripts or pipelines need to be in place, which is nothing more but algorithms, written by developers, who are called bioinformaticians or data scientists.

At the moment there are people working in science and R&D who have data and who can make sense of data analysis results, but they cannot setup running data analysis themselves. It's still being done in an old-fashioned command-line-geeky way and only bioinformaticians are trained to do the magic. This situation creates massive limitations and delays in making sense of the sequenced data.

Deploit is a SaaS product with a scientist-friendly interface guiding through running analyses with confidence and care.

Main Goals

“I love you my unscalable, inflexible and ugly platform”
— said no one, ever.

The goal at a high level is to have a simple platform with a secure cloud-based solution, saving money time and effort and being able to easily reproduce analysis and share results.

My Role

I came to the company as first and the only designer and my duties included full UX/UI support of the platform. Whether it was a redesign of existing functionality or working on the new, I owned the process from the very beginning to release and some testing.

Design Process

At the time I was working on the product, the requirements were coming from client demos. The two of the company founders have bioinformatics and computer science background. They are experts in the field and know what tools are missing on the market.

Normally the process was starting with a brainstorming session involving Dev and Stakeholders. After we were figuring out the flow, I was moving onto sketching. Sketching is a good way for communicating with developers and other designers, although, I found it’s harder to grasp the idea for the rest of the business. It was mainly done to verify everyone is on the same page.

After that, I was putting sketches into draft UI. I created a library of components so that helped me to produce interfaces swiftly. Then it was coming to the phase of verifying interfaces and prototypes with the users (if there were) as well as the product owner (in my case CEO) feeding insights into the next versions of a prototype.

Once there was a “go”, I was handing it over my work to a developer. During the development process, I was constantly overlooking and assisting him, whether there was needed an explanation on a feature behaviour, user journey or hand with exporting tricky assets. I have worked with exceptional devs who were able to use Sketch and Invision, so I didn’t have to do much of the assets exporting.

In such a busy environment, when we used to have x3 more task points than actually available time, our goal was always to minimise each other’s work. I was lucky enough to collaborate with the most amazing developers where that goal was mutual.

After a feature was live, I was assessing if everything was good from the UI and UX perspective. If there was a need I was making final tweaks on styling as I had access to the platform codebase.

UX-triage process

Here in the company, we had a Bug-triage process. Once a week developers met and went through the list of existing bugs deciding what is the biggest priority and is going to be fixed in the next sprint. I suggested having a similar process with UX issues. In Deploit, there’s a number of low-hanging fruit and fixing them would significantly improve user experience. I created cards in our zenhub board and suggested the same process. Luckily, this initiative was supported and the team agreed to pick at least two issues a week. Things started moving faster on the UX side! Whenever I had time, I was doing platforms QA and UX test as well as go through Fullstory records to identify the biggest frustrations.

The Challenges

Subject

Even though biology was amongst my favourite subjects at school, that knowledge was definitely not enough. I spent hours interrogating our in-house bioinformaticians asking them all sorts of questions trying to understand the nature of their frustrations. The high-level problems were:

• Lack of compute resources. Data gathering/management
• Knowledge management around analyses methods and workflows
• Benchmarking of workflows and tools

However, every time I was about to start working on a particular feature, I was investigating that particular case in-depth.

Startup nature

In a young company with aggressive expansion plans processes are getting tweaked and improving/changing every week. The team keeps trying various techniques to find the most efficient. Things will work if you are able to synchronize your own processes with the Team’s and keep the same rhythm. It’s important to keep your zen together when priorities change overnight.

Show must go

It’s a new product and we as a team needed to deliver (almost) no matter what it takes. It happens that sometimes stakeholders underestimating design and development scope. Then it’s my job to give a slightly more realistic estimate and ask the team to rethink the priorities.

Difficult to maintain a good quality of work

It’s a truly rewarding feeling when you see features you create are going live real quick. However, there’s a tradeoff and often I had to start work on something else before I can properly finish the previous piece. It’s crucial to find the balance between speed and quality, and sometimes I have to work on my drafts as if I’d have to hand them over tomorrow to the developer.

Different Audiences

When identifying different use cases we found two main groups:

R&D: Scientists, Research & Development
Who, most of the time, have data and questions to answer, however, have no idea which pipelines they can run against that data
Use case: select data and have a list recommended pipelines and what kind of results they would be able to get

Production: Bioinformaticians, Data scientists
They own pipelines which needed to be run with different parameters
Dashboard/monitoring metrics
Use case: selecting a pipeline and then choosing the data

Because of such a different nature and scenarios of analyses to be run, it’s a serious challenge to create software to cater to both groups.

Fragmented visibility

It happens when working on a feature, there’s an MVP part, plus there’s information about how the functionality will be evolving. With that information in mind, it’s easier to create something that will work for both: limited and extended cases.

In such a new product as Deploit, a lot of features were at the very early development stage with no visibility how they are going to evolve.

Deliverables

I started work on the product when it was on the closed Alpha stage. Within my first week, I was tasked to redesign the dashboard which later was developed within 2 weeks. It’s a truly rewarding feeling when the whole product is done by your designs. I felt impetuous delight every time a feature was going live.

“People figured how to synthesize diamonds, yet still no one knows how to create time” (c)

Deploit is free to use for individual users and it has its fans. To me, the most important is that the product I worked on is saving time in people’s everyday life. Last, but not least, it also has some paid contracts signed.