Where will this run?
Make the selected environment available at the point of execution and maintain orientation across tabs and panels.
Lenses SQL Studio / Developer experience / Product design
Know the context.
Understand the result.
Designing a SQL workspace that connects environment selection, query execution and record inspection — so technical users can keep track of what they are doing.
- Product
- SQL workspace for Kafka data
- Users
- Developers and
Kafka administrators - Focus
- Context, results and
execution feedback - Approach
- Interactive prototyping in Cursor
Concept feedback sessions
01 / The challenge
Keep the task connected
from start to finish.
The design brief focused on the uncertainty that can arise when users move between environments, topics, queries and technically dense records.
What did it return?
Support scanning records and opening their key, value and metadata without leaving the workspace.
What happened?
Expose execution statistics and problematic records so users can recognise when further investigation is needed.
A focused design scope
This case study covers the SQL Studio editor, result views and execution feedback. Kafka-to-Kafka replication is a separate workflow and is not used as research evidence for the editor.
Select context
Find the environment and relevant topic.
Write & run
Prepare the query and check where it will execute.
Inspect records
Scan the results and open the relevant details.
Review execution
Check the feedback and decide what to investigate next.
02 / Design decisions
A workspace built
around orientation.
Four connected decisions define the concept: visible execution context, inspectable records, parallel work and a separate diagnostic view.
01
Execution contextKeep the environment
Keep the environment
beside the action.
The environment selector sits immediately next to Run. The open menu combines search, a structured list and an option to hide disconnected environments, while the topic browser remains available on the left.
The design balance: A visible selector helps users check context; its effectiveness depends on clear behaviour when switching tabs, environments or active panels.
02
Result inspectionOpen the detail.
Open the detail.
Keep your place.
The results view presents record metadata alongside expandable key and value content. A detailed record and compact records can coexist, providing different levels of inspection within the same panel.
Metadata stays visiblePartition, offset and timestamp are positioned above each record.
Detail opens in placeExpanded content remains within the results workspace.
Views have distinct purposesResults and execution details answer different questions.
The design balance: The expanded view gives a record room, but reduces how many results fit on screen. A compact alternative is important for scanning larger result sets.
03
Parallel workTwo queries.
Two queries.
Two visible contexts.
The split workspace places an editor and result panel on each side. Each editor has its own environment selector, making parallel work an explicit part of the layout.
The design balance: The split view preserves two working areas at the cost of horizontal space. Meaningful tab names and a clear active-panel state become more important as the workspace gets denser.
04
Execution feedbackLook beyond
Look beyond
the returned records.
Execution details separate result content from statistics such as records fetched, scanned, skipped and flagged as bad. Progress and limit information provide another layer of feedback about the operation.
The design balance: A count can flag a problem without explaining it. A further iteration should connect the summary to affected records and an actionable explanation, where the underlying system supports it.
03 / Prototyping
Explore the behaviour,
not only the screen.
I used Cursor to build an interactive prototype and explore how the workspace could support everyday developer tasks. Working in code allowed me to experiment with different approaches before committing to detailed interface designs.
Explore
Connect the parts.
The exploration focused on environment selection, query editing and result inspection, including single-editor and split-workspace concepts.
Discuss
Make interactions tangible.
The prototype provided a shared reference for discussing concepts with developers and administrators, including how users maintain orientation between tasks.
Evaluate
Ask behavioural questions.
Which context belongs to each editor? How much space do results need? What information should stay visible when another panel opens?
The prototype supported design exploration. The interface screens do not establish a production integration or measured improvements in query performance.
04 / Research direction
Investigate how people
actually query data.
The research objective is to understand how developers and administrators select sources, execute queries, inspect records and investigate unexpected results.
This is a proposed SQL Studio discovery guide for a further research round. It is not a record of completed interviews, and the participant count from the separate replication research is not attributed to this project.
Start with a real task.
Ask participants to walk through a recent investigation. Focus on what they did, how they checked the context and where they needed more information.
Separate evidence from ideas.
Capture observed difficulties, workarounds and consequences. Use recurring patterns to form design hypotheses rather than treating a feature request as the underlying need.
Read the 20-question interview guide
Opening: please walk me through a recent task in which you queried or inspected Kafka data, without exposing sensitive information.
Context and everyday work
- What were you trying to achieve in a recent task, and what triggered it?
- Walk me through the steps you took, from starting the investigation to deciding you were finished.
- Which tools did you use? What caused you to move between them?
Environments and data sources
- How did you identify the environment and topic you needed?
- How did you confirm that you were working in the intended environment?
- Tell me about a time when the environment or connection state was unclear. What happened, and how did you resolve it?
- What information do you need about a topic or its schema before writing a query?
Writing and executing queries
- How do you usually start a query: from scratch, from an existing example or from previous work?
- What do you check before running it?
- While a query is running, what do you look for to understand whether it is behaving as expected?
- What makes you stop, change or rerun a query?
Results and investigation
- How do you decide whether the returned records answer your question?
- Which parts of a record do you inspect first? When do you need the key, value or metadata?
- Tell me about a recent unexpected result or problematic record. How did you investigate it?
- What information was missing, difficult to find or difficult to interpret?
Parallel work and continuity
- When do you need more than one query or result set available at the same time?
- How do you currently keep track of which results belong to which query and environment?
- What do you save or retain so that you or a colleague can continue the work later?
Priorities
- Which part of the task required the most effort or repeated work?
- If one part of this workflow became easier, which would have the greatest effect on your work, and why?
Follow-up prompts
Can you show a specific example? What happened before and after? How did you know what to do next? How often does this happen, and what is the consequence when it goes wrong?
05 / Evaluation
Test the connections
between actions and outcomes.
Evaluate whether the interface helps users recognise context, inspect records and interpret feedback while moving through a realistic task.
Developers and administrators were invited to sessions for feedback on the design concepts. A specific finding, design change and retest are not documented in the available material. The tasks below describe a proposed next evaluation.
Recognise the execution context
Task. Open two queries in different environments. Identify where each will run, then execute the intended one.
Observe. Correct identification of the environment and panel, checks before Run, hesitation and unintended switching.
Possible refinement. If context is lost, make the environment label more explicit and keep it visually connected to the query and results.
Find and inspect a record
Task. Find a relevant topic, run a query and inspect a record’s key, value and metadata.
Observe. Movement between the browser, editor and results; which details are expanded; and whether participants retain their place.
Possible refinement. If large records make scanning difficult, refine the balance between compact summaries and expanded content.
Understand execution feedback
Task. Inspect an execution that reports problematic records. Explain what completed, what remains uncertain and what is needed next.
Observe. Whether participants distinguish results from diagnostics and can identify a useful next step.
Possible refinement. If the bad-record count gives insufficient guidance, connect it to explanations and affected records, where technically available.
Work across two panels
Task. Keep a reference query open while adjusting a second query, then identify which results belong to each execution.
Observe. Recognition of the active panel, preservation of the reference state and attribution of results to a query and environment.
Possible refinement. If the split view creates ambiguity, strengthen panel identification and introduce meaningful query names.
06 / Contribution & next steps
Clarity is knowing
what belongs together.
The work demonstrates interface exploration and prototype-led evaluation of a technical workspace. The intended outcomes were clearer execution context, more readable records and more useful execution feedback.
Work presented
Interaction concepts and an interactive prototyping approach, with developers and administrators involved in concept feedback. The screens illustrate a direction for the editor experience.
Outcomes to establish
Production status and measured improvements in speed or error rates are not established in the available material. Further evaluation would focus on task completion, context-selection errors, feedback interpretation and assistance required.
What I would refine next
Use meaningful query names and a coherent sample dataset. Clarify the active panel and connection state. Improve compact result scanning and narrow-panel layouts. Connect diagnostic counts to explanations, then test whether users can choose the right next action.