Tesseract
A machine-learning platform with one dashboard and eight products behind it. Two of them are designed in full here.
- Discipline
- Product Design
- Work
- Research · Personas · UI
- Context
- Enterprise ML platform
Data scientists built models on personal laptops and shared VMs. There was no backup, no version history and no standard way to get from a notebook to something a business team could use.
Tesseract is a platform with one dashboard, Iceberg, and eight products behind it. Each covers one step: gathering data, building a model, watching it run, letting another team reuse it. This case study follows two of them to a finished design: DeepThought, where models are built and deployed, and Hubble, which monitors what DeepThought ships.
Tesseract: One Platform, Eight Products
Every user opens Iceberg, the dashboard. Behind it sit eight products that do the work: gathering data, building models, watching them run and letting other teams reuse them. This study follows one persona, Drew, through the four that touch his day most: Marlin, Hubble, DeepThought and Synapse. DeepThought and Hubble are designed in full.
Four of Tesseract’s eight satellite products show up in Drew’s journey - Marlin, DeepThought, Hubble and Synapse, highlighted above. The rest serve other journeys this case study doesn’t cover.
Agreeing on the words
Stakeholders used "AI", "machine learning" and "model" as if they meant the same thing. Before designing anything, the team needed one picture of what sits inside what, and which part Tesseract is responsible for.
What intelligence adds
Where the models sit
What that learning produces. The platform has to store, version, deploy and monitor models, so the unit of work is the model.
What is a model?
A model represents what was learned by a machine learning algorithm. The model is the "thing" that is saved after running a machine learning algorithm on training data, and represents the rules, numbers, and any other algorithm-specific data structures required to make predictions.
Meet Drew
Instead of designing for a generic "data scientist", I used one specific person. Drew's day, goals and frustrations are the yardstick for the rest of this study.
Drew
The Data Analyst - typical work in a day
Goals
- Help business teams with data required to make decisions.
Tasks
- Understanding the requirements
- Understanding the data
- Running data analysis using queries or Tableau or BOBJ
- Validating the results
- Dashboard creation
- Sharing results and getting feedback from business
Frustrations
On an average the analytics team spends a high bandwidth enabling, curating and validating data and in planning/meetings vs <10% in analytics.
Difficulties
- In knowing source of data and logic of each field
- In finding respective HAWQ SSE table in Tesseract environment
- In trusting existing data entities (certification process)
- Knowing relationships between different data entities
- Searching data
- In getting prompt response from IT on data questions
- High resolution time from Data engineers
- Provisioning data access
- Data sharing (grant access on tables)
- Running BOBJ generated query
The Data Science Journey
Next, where does Drew's work sit in the wider ML workflow? I mapped one model from requirement to dashboard. Every stage ended up on one line, and the trouble starts the moment the work leaves the conversation and needs somewhere to run.
Where to develop? Personal laptop, set up my own VM, or share a VM.
Everything is in my local. I do not have any sort of backup.
How do I deploy and build the model? I have to share VM resource to build.
How do I expose model output to the customer?
Lack of an integrated, standardised development process from writing the model to deploying it.
Increasing complexity that comes with the scale of a growing customer base.
Scaling is not possible if everyone has models in their own systems.
Infrastructure is a bottleneck, with 60% of models being heavy instances.
Lot of effort lost in redundancy of models being developed for each use case.
Hover or tap a stage to trace it down the map. Scroll the map sideways on a narrow screen.
Drew, In Full
Back to Drew for a moment. This is the fuller primary persona that the rest of this tab was designed against.
Drew
The Data Scientist - primary persona
Typical work life of Drew
Drew's work begins when his team receives an input from a business team about a data analysis that they need. He reaches out to gather the initial dataset from them to start cleaning and building his model. Usually he sets up the model-building environment on his personal laptop or in the VM resource that he and his teammates share. Drew monitors this model and stays in touch with the business team to format the output the way they need it, updating it for them regularly.
Tasks
- Build data models
- Monitor performance of models
- Provide consumable insights to business teams
Goals
- Reduce dependency on support teams for infrastructure needs
- Get more exposure for the models he is building
- Follow a standardised approach to develop data models
- Reduce operational problems of model development and get more time developing more data models
Frustrations
- No backup of data models created in his local if his system crashes
- Difficulty in maintaining various versions of models built in his projects
- Always waiting for infrastructure to get allotted for his models
So, What Is DeepThought?
The same few questions came up whichever team was asking: where to deploy, how to keep deployments consistent, how to avoid losing months of work to a crashed laptop. They were one gap. There was no end-to-end framework for the ML workflow, from a model on someone's machine to something the business could rely on.
DeepThought
An end-to-end data science platform
Deployment
Development
Marketplace
Three Pillars, One Platform
The gap split into three areas DeepThought had to cover: developing a model, deploying it, and letting other teams find and reuse it. Each area had its own version of the same complaint.
Deployment
- Where to deploy existing and new models
- Infrastructure is a bottleneck with 60% of models being heavy instances
- How to maintain these deployments
- How to be up to date with what is happening with our deployments
- How to use 3rd party visualisations to monitor models
- How to expose model output to customer
Development
- Where to develop - personal laptop, set up own VM, or share a VM
- Everything is in local, with no sort of backup
- Infrastructure is a bottleneck with 60% of models being heavy instances
- Avoiding data loss due to system crashes on personal laptops
Marketplace
- Increasing complexity that comes with the scale of a growing customer base
- Scaling is not possible if everyone has models in their own systems
- Lot of effort lost in redundancy of models being developed for each use case
The Platform, In Screen
Three screens from the concept: the developer workbench where a model gets built, the project detail Drew opens to check a deployment, and the model catalogue where another team can pick up a finished model.
