Driver AI Redesign
Working with a team to fully redesign a startup company's website, from start to finish.
- Project: An Iterative Redesign
- Role: UI/UX Designer
- Timeline: 3 Weeks
- Skills: Teamwork, Figma, Design Flow
Overview
Understanding how to execute a full iterative design process from start to finish is extremely important for founders, designers, and engineers alike. Being able to take a problem statement to a clicakable protoype is a test in both design and teamwork skill, and as an exercise gives a better understanding of the creation process as a whole. My team and I reached out and received a design problem from a real Y combinator startup company, and fully redesigned their website, from clarifying the problem all the way to presenting a full design prototype to the founder, with multiple refining steps throughout.
Many companies struggle with complicated code bases that make it difficult for developers to onboard new employees, remove tech debt, and create new code. Driver AI is a startup powered by LLMs dedicated to helping software teams organize and innovate. We went forward with redesigning the organization of the LLM generated technical documentation to be easily and quickly accessible to users. This should give users the context they need to understand the documentation they are reading, while making clear to users what actions are available to them for editing and creating documents.
This project personally taught me a lot about being a part of a team and the art of bouncing ideas and progress off of each other in order to move farther and do better together. I believe that this project also showcases my design skill, since I think it is important to understand the fundamentals and nuances of design, in order to better work with industry designers when discussing ideas from a developer perspective!
Clarifying the Problem
In order to begin, we had to first understand and clarify the problem. We were given a project brief by DriverAI, detailing the problem and what they were looking for. Our task was to redesign the company’s content organization and navigation, in order to create a more simple and seamless flow for users, and to be able to more cleanly showcase content. In essence, we were tasked with a redesign of their user flow. After receiving our brief we met and discussed it, and most importantly took the time to analyze the userflow of the current implementation of DriverAI, which is pictured below! After taking both pieces of info, we wrote up clarifying questions to ask the founding engineer, focusing on asking about the purpose of each organizational level (Workspace, Codebase, and Dashboard), what features users found important, and looking for where he thought the current main pain points were.
Sketching
The next step was to get our ideas down on paper through sketches. The four members of our team completed a round of 8 sketches, with two end-to-end flows comprising of four screens each, all pictured below. My work was the set of sketches on the top left, and after discussing heavily what worked and what didn’t, I contributed to the team with my sketches being the most closely followed when moving on to the figma wireframes!
The First Wireframe
Following our sketches, we sat down to discuss how we wanted to proceed, talking about each others ideas and looking at the sketches to determine how we would approach the problem. We made a few major design decisions at this stage that we carried over into our wireframe. Within DriverAI, there are three main page layers: The dashboard, the Workspaces, and the Codebases. We felt that there was too much of a buffer between where you begin and where the meat of the content actually is, which made our primary concern removing the fluff and creating a simpler experience with fewer clicks. That is why we decided to keep from our sketches the idea to remove the Workspaces level and put it within the top level of the website, as well as our sketch idea of a collapsable sidebar. Below you can see the rest of our notes from that discussion, which showcases our design decisions, of which many features can be seen on our wireframe, also linked below, with the intended impact.
The Critique
After completing our first wireframe, we showcased it to both our peers and the founder, and received diverse and useful feedback to help us improve our work. For our peers, we recorded a Loom video walking through the entirety of our first wireframe, and collected notes on the feedback we received, getting advice on what worked well, and what could be a little more clear. Below is the link to our first Loom video:
Afterwards, we compiled all of the information the founder needed to know, and emailed it to him along with our Loom video, setting the date for our final zoom discussion meeting with him. He also gave us very detailed and helpful notes, which are featured on our Figma file for our first wireframe, linked earlier.
We compiled and distilled the feedback we received from both groups into the following critical points:
Notes From Peers:
Positive:
– Very clean, intuitive
– Workspace vs. codespace distinction is now clear
Suggestions:
– Can only look at one note at a time… maybe want more?
– Do we want to design a system where people can view most recent notes?
– Spend time thinking about how we want to organize nav bar
– 64 pixels of padding & include spacing guidelines in style guide
Negatives:
– Name “the hub” not very intuitive
– If you’re in the workspaces page, how do you get to the Hub, how do you get back to the workspace? (not very clear… i hope this should be more clear in the hi-fi?)
– Expanding code section – looks a bit messy (how much do we prioritise showing things?)
– Distinguish between notes, files/tech docs, and resources
Notes From Founder:
General notes:
– “Navbar” at the top with different levels of nesting is very unclear.
– Move “executive summary” and “entry point” into tech docs
– Rename notes to something else? Something like “README” or summary
– Dropdown menu hard to distinguish from rest of site
Responsiveness:
– I’d recommend not worrying about responsiveness this early.
– Focus on the main use case – desktop – then make adjustments for other screen sizes.
Levels:
– Think about the level of nesting these have. Keeping is as simple as possible is ideal!
– Glad y’all were able to leverage some components without getting bogged down creating one for every UI component. Definitely isnt necessary!
– I would have at least two levels of dark text
– Primary (zinc 900), Secondary (zinc 600), Disabled (zinc 3 or 400)
– Design systems for color can get crazy! Keeping it simple is ideal for this body of work!
The Second Wireframe
After reviewing our suggestions and having another discussion, we cleaned up our design and created a second wireframe, with some added features! The main thing was that we added a new workspace/codespace navigation sidebar, in order to make the transition between pages easier, with a constant being there to remind users where they were, and that allowed them to go backwards easily. We also used our suggestions as validation to make the step to removing “The Hub” page. It was within the Codebases level but acted only to view notes, so we renamed the page and merged it with resources, a similar page, to reduce redundancy! There were a few suggestions we ended up not taking, such as expanding back the workspaces page to act more as a hub, as it did not align with our plans to reduce clicks.
High Fidelity Prototyping
Our next and possibly largest step was to create a clickable high fidelity prototype to present to DriverAI. We started with the style guide, in order to have a clear and consistent vision of what the website would look and feel like. We were not provided a style guide from the company, but we did however, implement a version of our own style guide in our low fidelity wireframe, and was able to get suggestions from the founder on it. We used those suggestions as well as some of our own reasoning to create our own high fidelity style guide! For color, the website itself already favorted a black and white design, with little to no color, so we instituted the same. We also added some flavor through our selection of icons, to be used to denote different workspaces. We went with the zinc pallete in order to have clean consistent white grays and blacks. The founder suggested we add two levels of dark text and keep the style simple, along with having a smaller radius on our corner values, all of which we implemented in what is our final style guide below:
Finally, we had all of the parts, ideas, and advice needed to create our high fidelity prototype. When starting to create our final high-fidelity mock-ups, we decided to turn back to our brief. Our main task was to reduce unnecessary nesting while also allowing new users to better understand already existing features. This is the cornerstone of our re-design, so we wanted it to be as present as possible in our mock ups. We also wanted to deliver a style that fit Driver AI’s monochromatic display and ARC browser design inspiration. Workspaces – We wanted a list display of items and a sidebar that allowed for notes to be shared across an entire workspace. Codespaces – We found this generally intrusive and unnecessary, so we wanted to reduce the amount of user time spent on this page as much as possible. Most of the functionality was brought up into Workspaces for this reason. My Dashboard – this page was the new page that combined the old Hub and TechDocs pages. It is designed to be the user’s main interface with Driver AI. Here, they should be able to view both code and the LLM generated documents. We also wanted users to know that they could edit the information with shortcuts, so we want to include an expanding text-editor. The new sidebar will help users move throughout the website. With all of this detailed, we created our High Fidelity Figma!
Accessibility: Our redesign completely follows all WCAG. This is in part because of the monochromatic coloring. This was a design choice specifically given to us by Driver AI. However, we made sure that all of our elements were in clear contrast to their backgrounds. Although we have no true prototype of the website, if we were to develop it we would be sure to include full alternative titles for all of our images. We also designed the website to be completely key board navigational. It does not rely too much on specific buttons and has an easy user flow. The side-bars also help further our accessibility initiative because they both follow a strict visual hierarchy, but also are collapsible, so the user can focus strictly on the main LLM document.
Final Founder Feedback
After putting together our final prototype, we created a second Loom video which walks through every screen that we created and explains our design choices. We sent the loom video and our figma file to DriverAI, and then the following day, had a zoom meeting with the founder Ryan Bolick, in which we discussed all of our major changes and design ideas, and got some amazing advice and final thoughts from him! Below you can find the link to the Loom we presented, as well as our notes from his final suggestions and a summary:
Dashboard (previously Techdocs) comments:
The founder found the swapping between source code and tech docs to be interesting, as this was something the company had not previously thought of. Additionally, he really liked the favorites function to allow users to save important documents. Finally, he liked the text editing feature on techdocs, but thought the wrench symbol wasn’t very intuitive.
Codebase Summary (previously The Hub) comments:
Likes the rebranding of “the hub” to “the summary” and really liked the dropdown menu to the left. However, the founder thought some buttons could be replaced, like “show more” and certain “…” buttons. Additionally, he wanted to remove the codespace and workspace filtering.
Workspace comments:
The founder liked the symbols replacing colors. However, he wanted us to switch the workspace descriptors with the codebase lists (because the summary should be more important). He also wanted us to make some things more intuitive by switching their positions on the screen.
Implementing Feedback
After our final meeting and gaining great feedback from the founder, we decided that we would go ahead and implement some of those recommendations, in order to have an even better final design! We made changes to the three major areas that were commented on: the dashboard, codebase summary, and workspace.
Dashboard:
This implements the major pieces of feedback we received for the Dashboard. First, we changed the wrench on the tool box to be a more appropriate item. This should be a dropdown for tools to help edit the text, so we changed it to be a pencil! Next, we increased the default size of the favorite section. This makes it easier for users to select their favorite notes. Additionally, we also added a default sorting method for the favorites by files first and then notes. Previously they were just mixed together. Below this we also swapped the order of the notes and files button. These buttons serve as filters to show the hierarchy of the results below them. One of the main pieces of feedback that we got from the founder was that these should be above the filter to better fit with a hierarchy of information.
Codebase Summary (previously The Hub):
As per the founder’s suggestions, we removed the “…” above the codebases in the sidebar and renamed the “show more” buttons below the list of documents and resources. Finally, we removed the new document button for resources (because the resources aren’t generated by their AI), and tidied up the search bar area.
Workspace comments:
We made two major changes to the Workspaces page incorporating the feedback from the founder. First, we swapped the search bar on the left column with the sorting feature, to put the search closer to the content it was associated with. Then, the next major change we implemented was to swap the Workspace notes (including the summary) and the list of the codebases. This means that after a Workspace is selected, a dropdown appears listing all of the Workspace-level notes, and the list of Codebases for that Workspace will appear on the right-hand side of the screen, where one can be clicked on to navigate to the page for that Codespace.
Conclusions
Overall, I gained some incredible insights on the full design process! Going from A to Z provided me with a better view of the bigger picture, and how they all connected. Just as importantly, it taught me how to work efficiently and collectively as a team in order to come up with a better product through all of our ideas and efforts. In the end, I am very happy to report that Ryan loved our final design, and congratulated us on our work. We received some amazing feedback, and I would love to thank Ryan Bolick and DriverAI for providing us with the chance to design for them!
