Tesseract
A Platform-as-a-Service with one dashboard and eight satellite products behind it - two of them designed in full here.
- Discipline
- Product Design
- Work
- Research · Personas · UI
- Context
- Enterprise ML platform
Data scientists were building models on personal laptops and shared VMs, with no backup, no version history, and no standard route from a notebook to something a business team could actually use.
Tesseract gives that work a home: a single Platform-as-a-Service with one dashboard, Iceberg, and eight satellite products sitting behind it, each owning a piece of the workflow - gathering data, building a model, watching it run, letting another team reuse it. This case study follows two of those eight through to a finished design: DeepThought, the developer workbench and deployment path, and Hubble, the monitoring layer that watches what DeepThought ships.
Tesseract: One Platform, Eight Products
Start with the shape of the thing. Tesseract is a Platform-as-a-Service - one dashboard, Iceberg, that every user opens, sitting on top of eight satellite products actually doing the work behind it: gathering data, building models, watching them run, letting other teams reuse them. This study follows one persona, Drew, through the four that touch his own day most directly - Marlin, Hubble, DeepThought and Synapse - and designs two of those four, DeepThought and Hubble, 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.
First, The Vocabulary
Before designing anything on top of that platform, the room needed to agree on what it was actually building. Every stakeholder used the words AI, machine learning and model interchangeably, and they are not interchangeable - the team needed one shared picture of what sits inside what, and of which piece Tesseract is actually responsible for.
What the intelligence actually adds
And where the models sit inside it
What that learning actually produces. Every thing the platform has to store, version, deploy and monitor is a model - which makes the model, not the notebook, the unit of work.
So what is a model, exactly?
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
With the platform mapped and the vocabulary settled, the design needed a specific person to sit inside it rather than an abstract "data scientist" - someone whose actual day, goals and frustrations the rest of this study could be measured against.
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
With the words agreed, the next question was where Drew’s work actually sits in the wider ML workflow. Mapping one model end to end - requirement in, dashboard out - put every stage on a single line, and made it obvious that 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
Before opening DeepThought up, it’s worth going back to Drew once more - not the lighter analyst framing from earlier, but the fuller primary persona the rest of this tab was actually 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?
Strip away which team was asking, and the same handful of questions kept resurfacing - where to deploy, how to keep deployments consistent, how to avoid losing months of work to a crashed laptop. None of them were really separate problems. They were one gap: 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
That gap split cleanly into three areas DeepThought had to own - developing a model, deploying it, and letting other teams discover and reuse it once it exists - each carrying its own specific version of the same underlying 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 specimen screens from the concept: the developer workbench where a model gets built, the project detail Drew opens to check on a deployment, and the model catalogue that turns a finished model into something another team can just pick up.
