This case study documents work completed at OptimusBT. Some UI details, brand elements, and naming conventions have been modified to respect confidentiality obligations. The design process, reasoning, and decisions described are accurate.
Overview
Smart Column was one of the concepts I designed for Astra, an AI layer integrated into an enterprise workflow. The idea was to let users generate new table columns using natural language instead of manually extracting information from documents.
I was the sole designer responsible for the feature, from early concepts to high-fidelity prototypes.
At first, I thought I was designing a better way to ask AI for information. As I gained a better understanding of how the feature would fit into existing workflows, the problem itself gradually changed. Every new discovery about the workflow influenced how I thought the interaction should behave, eventually leading to a very different solution from where the project began.
Constraints
This exploration was completed within a limited timeframe, which influenced how I approached research. Rather than conducting primary user research, I relied on stakeholder discussions, representative datasets, and secondary research through existing products to understand the problem space and evaluate interaction patterns.
Although this meant I couldn't validate the concept directly with end users, it allowed me to quickly explore different directions and iterate on the interaction based on the information available during the project.
Understanding the Problem
The project began with an exploration of how AI could become part of an existing table experience within Astra. Rather than building a standalone chatbot, the objective was to understand how AI could help users work with structured enterprise data more effectively.
As a starting point, my manager shared Hebbia as a reference because of its AI-first interaction model. Instead of treating AI as a separate assistant, it became the primary workspace for exploring documents and structured information. That interaction became the foundation for my first design exploration.
Exploring the First Direction
My initial concept placed AI at the centre of the experience, with the table acting as supporting context. Users interacted primarily through conversation, allowing AI to answer questions and surface information from structured data.
At this stage, I was focused on making AI feel more capable than a traditional chatbot. The interaction answered the brief I had been given, but it also revealed an important limitation during the first design review.
Low-Fi Design Exploration based on Hebbia
A Change in Direction
After reviewing the initial concept, my manager suggested shifting the exploration towards generating AI-powered columns directly within existing tables. Rather than treating AI as the primary workspace, the table would remain at the centre of the experience.
This was the first major change in the project. The feature was now focused on helping users extend the data already available in a table instead of replacing the workflow with a conversational interface.
Initial concept following the shift from an AI-first interface to a table-first workflow.
Reframing the Problem
Around the same time, my manager shared a representative CSV containing the kind of data users worked with every day.
Looking through the dataset raised a simple question: How are users currently working with this information?
After discussing the existing workflow with my manager, the bigger picture started to emerge. Users exported data into spreadsheets, referred back to contracts and supporting documents to fill in missing information, and repeated the process whenever new records were added.
Understanding that workflow changed how I approached the feature. Any AI-generated column would eventually become part of that reporting process, which meant the interaction needed to support more than generating values. Users needed opportunities to review, refine, and trust the information before adding it to their table.
At this point, the design challenge became much clearer. The next step wasn't to design another AI interaction. It was to understand how AI could fit naturally into a workflow that people were already using every day.
Designing the Experience: Learning from Existing Patterns
Understanding the reporting workflow raised a new design challenge. The table had become the primary workspace, so the interaction needed to support AI without pulling users away from the data they were already working with.
Before designing a new interaction, I looked at products that already combined AI with structured information. Notion AI demonstrated how AI could be introduced through inline prompting, Airtable AI showed how generated fields could become part of an existing dataset, and Ruli explored AI-assisted document extraction within structured workflows.
Although each product approached the problem differently, they all shared a similar interaction model. Users described what they wanted, AI generated a result, and the interaction largely came to an end.
Rethinking the Interaction
That pattern worked well for straightforward requests, but the reporting workflow I was designing for introduced a different set of expectations.
A generated column wasn't simply another AI response. It would eventually become part of a report that people reviewed, shared, and made decisions from. If the generated output wasn't quite right, asking users to rewrite their prompt and generate another column felt unnecessarily repetitive.
I wanted the interaction to feel less like issuing a command and more like working through a task together.
Instead of treating every prompt as a separate request, the conversation remained active throughout the process. Users could clarify their intent, refine the generated output, ask follow-up questions, and continue shaping the column without losing the context established earlier in the interaction.
The goal wasn't to make the AI more conversational for its own sake. The conversation became a practical way to refine information before it reached the table.
Conversational Smart Column flow.
As the interaction evolved, I found myself designing around the moments that happened after the initial response.
Previewing generated values gave users an opportunity to review the output before applying it to the table. Source references helped explain where individual values had been derived from. Keeping the conversation attached to the Smart Column meant users could return later, continue refining the results, or understand how a particular column had been created without starting over.
These decisions gradually transformed the feature from a single interaction into an ongoing workflow that supported review, iteration, and confidence.
(Left) Preview before applying generated values. (Centre) Source references linked to generated information. (Right) Smart Column information and conversation history.
During these iterations, the feature also evolved beyond its original working title of AI Generated Column. I started referring to it as Smart Column, a name that reflected how the feature behaved rather than the technology behind it. The name was eventually adopted throughout the subsequent design explorations and prototypes.
Considering Edge Cases
Given the limited timeframe, I focused on designing the primary workflow first, leaving edge cases for a later iteration. Although I identified several scenarios during the exploration, the project concluded before they could be explored further.
One of the biggest questions centred around corrections. If a generated column contained a single incorrect value, what should happen next? Should users edit that individual cell directly? Should that cell open its own conversation? Or should refinements always happen at the column level to preserve consistency? I also considered how Smart Columns would behave in collaborative environments. Should every user be able to create their own Smart Columns? Would conversations belong to the person who created them, or become shared across the workspace? Answering these questions would require balancing product requirements, technical constraints, and the overall complexity of the experience.
Final Experience
By the end of the exploration, the interaction had evolved from an AI-first workspace into a workflow centred around the table itself. Rather than asking users to jump between disconnected steps, the experience allowed them to create a Smart Column, review the generated information, refine it through conversation, verify supporting sources, and apply the results only when they were confident with the outcome.
The following walkthrough brings those interactions together into a single end-to-end experience.
Complete Smart Column workflow, from creating a column to applying it to the table.
Conclusion
Smart Column never progressed beyond the prototype stage, but it remains one of the projects that had the biggest impact on how I approach product design.
When I started, I thought I was exploring AI interactions. As the project evolved, I realised that understanding the surrounding workflow was just as important as designing the interface itself. Each new piece of context gradually changed the problem I was trying to solve, and the final concept looked very different from the direction I had started with.
That experience made me much more comfortable treating design as an iterative process of discovery. Rather than becoming attached to an early idea, I learned to let new information reshape both the problem and the solution.
