Designing for AI Engineers: UI patterns you need to know
A reference article with guiding principles, patterns, and personas to help designers become more AI literate.
As the Head of Design at Modular AI, my team is going from 0 to 1 on a lot of AI products and workflows this year. Even though I’ve been designing for developers for years, I’ve personally had to quickly ramp up on some AI specific topics and build out our personas, so I thought I’d share a few best practices and top references I’ve established for myself.
Guiding UI principles:
- Condensed information is welcomed. Much like the B2B industries of data science and fintech, these personas welcome dense data — as well as it’s designed with a strong hierarchy. So, reduce those margins!
- Parsed metadata is the most clear. Extracting out the metadata and making it search/filter/sortable is important. Tables, side drawers, tagging systems — these are the main design system elements to refine.
- Remember Jakob’s law — user’s spend more time on other sites than your own. There are strong leaders in AI, such as HuggingFace and OpenAI. If they’ve established a pattern and there’s no strong reason to deviate, go with it. I know, I know, this goes against first principles, but there’s a time and a place for first principles. I’lll leave it to you to decide that for your team and roadmap.
A great sources for designing for developers is Github’s design system. Here are a few of their principles that are clearly custom to the developer persona:
- It’s not fully shipped until it’s fast
- Anything added dilutes everything else
- Practicality beats purity
- Approachable is better than simple
- Half measures are as bad as nothing at all
- Encourage flow
- Favor focus over features
So with those principles in mind here are some key interfaces that my team has released this year. Keep in mind my team is 4 people (2 designers & 2 developers), and we’re a fast-paced start-up. Our designs are all released as MVPs at first, then iterated once live, and often built off of existing systems to get from 0 to 1 and get real external validation as fast as possible. All of the designs in this post were created by myself and Will Rust together. Design is a team sport.
The screens I’ll cover:
Product 1: Chat with an LLM (Simple marketing page version)
As end users, we’re very familiar with chat interfaces by now. Chatting with an LLM (large language model) as a developer is almost identical to the end user experiences on AI platforms like Chat GPT, Duck Assist, or Perplexity. It’s about being as clean as possible and providing fast and concise answers.
The main difference is that an AI developer is also evaluating the model in terms of it’s speed, ease of building on top of it, it’s compatibility, and deploying it.
Keep it as clean as a traditional search engine, but offer a subtle 2nd layer of what’s happening under the hood, including things like links to the documentation, benchmarking data showcasing the speed of the model, and other data such as cost per token . Here is how we solved for that at Modular.
UI frameworks we used: https://www.gradio.app/, Mantine, Tailwind
Screen 1 — simple ‘start chatting’ intro screen showing the user which model it is, what hardware it’s running on, and the traffic volume it’s handling.
And of course everything is light/dark mode compatible. Here’s the darkmode version where we embedded the chat inside our developer console.
Screen 2 —chat results, showing benchmarked data, as well as links to tutorials, the code, and next steps for deployment of this model.
Screen 3 — The embedded version. For this version, we trained MAX specifically on our documentation using RAG. We started this experiment for internal users only and are hoping to release soon.
A few choice references:
Product 2: Model Repository
One of the most important things that an AI developer needs to do is evaluate GenAI models. This starts with searching through a model repository — also called a ‘model garden,’ ‘model library,’ or ‘model hub.’ For marketing/SEO reasons, this is usually a logged out experience, with the main goal being to show users all the models that your platform is compatible with, and encouraging them to log in if they want to test the model more seriously. Our model repo is live at builds.modular.com
The most important features here are essentially search and filter. You want to make sure the user can find what they’re looking for, from a large dataset of what might be hundreds to thousands of models.
Screen 2 — Model detail page. This page tells the user how many variants we have of each model, how to quickly run the model locally, and how to deploy it to a GPU in the cloud if they want to.
There are some fun technical details related to model parameter size, quantization, hardware compatibility, etc. But in the end it all comes down to gestalt clustering and creating the right hierarchy.
My top references here are Huggingface (because they’re the leader in this space), Kaggle (because they have a thriving community) , together AI (because they’re Enterprise), and Replicate (because 80k hits per day is alot):
Like with all successful UI, keep in mind the users mindset here. The AI developer is thinking about models in terms of what task the model can complete, the size of the model, it’s performance, and who made it.
Product 3: Playground
A playground refers to an environment designed for experimentation, testing, and learning without the risks of affecting live systems or production environments. For AI developers, it more specifically will include things like trying out the AI models, testing prompts, and fine-tuning parameters without the need for extensive infrastructure.
We’re just getting ours up and running now, so I’ll just talk about the main features and show some references.
Main features:
- Logged in and Billing connected. Just a small note, but users usually need to connect a credit card because you’re officially running AI compute now.
- Sliders to control the model’s parameters, change the model entirely.
- Pay-as-you-go pricing
This segues perfectly into the whole console experience.
Product 4: Developer Console
From a layout and information architecture perspective, this is like any other desktop console. We use tailwind, mantine, and chartjs to make ours.
The fun UI features here are the data monitoring dashboards. If you’ve ever designed an Enterprise dashboard then the rest honestly is the same — Role based access control, billing, organization hierarchy with members inside that can invite other members, notifications, settings, etc.
Product 5: Documentation
Ok, let’s get into some bread and butter — Documentation! Everyone’s favorite thing to design ;) Here’s ours. This was actually my first time ever fully owning the design of a documentation site. We use Docusuarus for ours, as well as Algolia search, which has fantastic UI out of the box!
As far as the information architecture goes, we’ve discussed a few approaches here, and narrowed in on two overarching concepts:
- Follow the user’s JTBD (jobs to be done) — in what order do they accomplish these tasks. For us, it’s: test locally, serve, deploy to cloud, monitor, scale.
- Follow the architecture of your product. For us, we have a whole platform that goes from low-level GPU programming to auto-scaling in cloud, so this is also compelling for us to categorize in this way.
Whichever you choose, a landing page that reiterates this is critical.
Our most visited page is our ‘Quickstart’ (not surprisingly!). And we’re continuously optimizing this page for faster competition, and higher completion rates.
Some references:
And as I mentioned, Algolia search is fantastic. Here’s how it looks for us:
Product 6: Recipes & Code
Recipes (or cookbooks) is a silly, yet standardized way, of referring to step-by-step instructions. In their most interactive form they are notebooks, where each section is executable code. In their simplest form they’re just a series of instructions with copy/paste-able code snippets.
As I mentioned, we build extremely iteratively, so our MVP is truly just rendering a github code example, with metadata called out on the right. I find this this audience, the cleaner and simpler the better. The content itself is so dense, the design shouldn’t call attention to itself.
A large part of the design system for these articles, is just how you render code, so having an organized system for light and darkmode is a key focus. We use mantine system for this and set our custom colors there, and you can lean on established best practices for CLI color schemes, as shown in this article: https://hamvocke.com/blog/lets-create-a-terminal-color-scheme/
And don’t forget to have some fun with the CLI, ascii art, and clear progress bars! For UX of the CLI, I just try and teach my engineering teammates the basic 10 NNG principles, and the top one leveraged is ‘visibility of system status’.
What’s next?
I’m really excited to build so many more workflows and share them. I hope to focus on agentic workflows and cloud monitoring dashboards next.
Bonus image — AI Engineer Personas
As a reference, here is a genericized version of the personas that I created for Modular. Our bullseye is the ‘Solution Builder’ for now.
Stay tuned, and thx for reading.
Eve
