Designing and Building GenAI Experiences

Disclaimer: Any designs featured here are recreated with all project-specific information removed

It’s so hard to talk about working in tech without mentioning AI now. So when I had the opportunity to work on various applications that utilized Generative AI, I took this as a chance to better understand what the hype was all about. Through this project, I tried to better understand GenAI and how it would be best applied, while building up my technical skills.

My first experience working with GenAI was essentially a month-long hackathon. I joined a project to implement high-fidelity designs given to me by the team’s designer. The goal of the project was to streamline paperwork for healthcare professionals so that they could focus more on the savings lives part of their job. At this stage, I was brushing up on my technical skills in React and Material UI, since I was just following the design itself. Throughout the implementation, I made sure to follow up with the designer to make sure that what I built was following their vision (a sneak peek at my next post – I experience working as a designer and I totally understand the hardships of a designer now…). 

Because the front-end is where API calls happen, I was responsible for implementing the API calls and worked with the AI engineers that were responsible for writing the code to call the models we use to make sure the prompts and responses were being sent and retrieved properly. I thought the project went well, despite jumping into it in the middle and for only one month. Early on, I had seen a very realistic application of GenAI. The use case made sense – it reduced the unnecessary workload for workers and contacting relevant people in a crisis situation.

Building a prompt testing UI

The next project I worked on was for a prompt testing feature for an internal GenAI application. This feature would serve as a tool for that users could use to refine their prompts and getting better, more accurate responses. This was the first time I was working in both a designer and developer capacity. First, I would have conversations with the AI specialists on our team to better understand the requirements needed for this feature. Then, we would iterate through designs until we settled on one. In this phase, I was pretty new to requirement gathering and wasn’t sure how much information I needed to make a design. I knew that the style was pretty solidified; we were going to be using Material UI and I could reference other parts of the application to get a sense of a cohesive visual design. Because we were doing a prompt testing feature, we looked at design choices by existing prompt testing tools out there, such as the one by Anthropic. But what was certain was we needed: a way to select what model to use, a way to type in a prompt to be improved, a way to edit a generated prompt, and a way to compare the results of both prompts.

The revised prompt would then structure the inputted prompt into something similar to the free-form structure in the design below which contains 3 parts:

There are many other prompt structure types that could generate better responses depending on the use case and type of LLM used. In the case of a free-form structure, this is better at addressing complex questions.

A revised design of the prompt testing UI

The next phase of the prompt testing feature was to include a way to compare test cases. We knew we wanted them to live in a table where each test case could be seen easily, so I decided on using a sticky column for the results.

Wrangling with code and learning new tools

After that, I worked on an experimental GraphRAG tool that would take information from an uploaded document and synthesize the information into a visualization and a chatbot that can be used to dig deeper into the details of the document. 

A really good use case for this was if you had a large document that you needed to pull important information from in a short amount of time – with the drastic changes being made by DOGE in 2025, this was a very real reality for many people. RAG models are interesting to work with because they can directly reference and pull information from specific materials, making it an alternative to lessen the hallucination issues that regular LLM models face. 

On this project, I faced a challenge of learning both neo4j, which was the database being used, and D3.js, the JavaScript library used for creating the visualizations. On top of that, I inherited a codebase that didn’t have much documentation around it. Luckily, I was still able to chat and call with the original developer, who was able to give helpful pointers. Even though it was hard and I did use Copilot a lot, eventually it just started to click once I was able to figure out the whole pipeline – starting from the database connection, to parsing the data, and to finally rendering the data into a visualization. It was really challenging but also really fun seeing the results in the end and to just make a fun-looking visualization.

Here I modified a D3.js circle pack graph to represent the relationships of the data starting from the topmost hierarchy, which is referred to as a “Community” here in the design below.

me trying to figure out if my data retrieval or data parsing or maybe my whole career path was the issue

Honesty, I was fighting for my life learning neo4j. It was a whole new language I had to learn and I was a little intimidated. The closest thing I could compare it to was SQL but not. Most of my issues with this involved data retrieval through axios connection and parsing the data in React. But once I was able to finally understand the whole pipeline, it finally became fun.

D3.js also required a learning curve for me but I actually quite enjoyed it, despite it being frustrating at times. One example is when I was trying to add custom labels onto the circle pack graph. Because of the order in which things are rendered in the circle pack, I had to work through parsing the data so that 1) I would have the label info that I needed to render and 2) that it would be drawn after the rest of the graph is rendered so that it wouldn’t be covered by the other circles.

Reflection and thoughts on GenAI

Not only did I learn new skills, but I also gained new insight into the different perspectives required for being a developer vs a designer. As a developer, you’re typically dealing with a small part of a larger system and focused on implementing a feature at a time. But as a designer, you have to consider the big picture, the business value, and communicate that value across through the design.

Working as a designer and developer helped make me see both my strengths and weaknesses. One feedback I had continuously got was “the UI needs to be more polished”. I realized that I needed to train my visual language better until I could create designs that looked more professional. So at the same time, I’m very detail-oriented, so I was able to spot places to fix and improve my designs.

With the rise of AI capability in tech, the sparkles icon has become increasingly representative of AI capability. Sparkles present these AI features as “mysterious” and “magical”, which isn’t a great image to have considering AI-induced psychosis is on the rise. But because of these incidents, more people are realizing that AI is not something magical, it can and will produce inaccuracies, and it’s really only as good as what you give it. It’s really good at identifying patterns, but not reasoning what patterns would actually occur in reality. I hope that once more people take off these rose-colored lenses for AI, and when AI tools are more normalized and treated like another capability, their association with sparkles also phases out. Make a cute little robot or character! Be creative! And get specific about what it’s doing.

In my experience with using AI tools like Github Copilot to aid in my work – it’s truly powerful and a time saver for those searches I would do when silly little me forgets how to, for example, center an image in a div. For more complex problems, however, I found I needed to provide as much context for the problem as I could and also include multiple files for my prompt to get a helpful and relevant answer. I think the time doing that takes away from the time spent solving the actual problem itself. Maybe the oldie in me is just still used to StackOverflow and just the plain old, asking your teammates for help. Pair programming is great and has been a very effective learning tool for me.

With powerful tools at our disposal, it can be so tempting to just send prompt after prompt, and hope that it’ll spit the right answer out. I can now appreciate that I learned how to code before the proliferation of AI. The problem-solving skills I learned are invaluable and the number of times my code has broken over the years has greatly humbled me. I tend to learn better from experience, and if I make a mistake, it will be cemented in my memory and it’ll probably replay in my head many times before I fall asleep. So my takeaway for when you’re learning something is to try and fail, before resorting to using AI tools.

Libraries/Software Used: React, CORS Middleware, Material UI library, fetch API, axios, D3.js, Docker, neo4j