The Fastest Way I’ve Found to Build a Solid UI Without a Designer

Over the years, I have built new products, redesigned existing ones, worked without a designer, and worked with designers who could only give the team a limited amount of time. In all those situations, I faced the same question: what is the fastest way to turn product requirements into a solid interface? By solid, I mean an interface that looks good, is easy to use, works across different screen sizes, and does not become inconsistent as the product grows. I have tried exploring layouts in Figma, adjusting the interface directly in code, borrowing ideas from other products, and asking Claude or Codex to generate designs. These approaches can help, but they often leave us with several possible directions and little confidence about which one to follow. The fastest reliable approach I have found is to start with an existing, mature design system and adapt it to the product. The fastest foundation I have found When we build a backend, we rarely start by creating our own database. We choose PostgreSQL, MySQL, or another proven system. This lets us move faster and focus on the data and business rules that make our product different. An existing design system gives us a similar foundation on the frontend. A mature design system usually provides: - Rules for typography, color, spacing, and visual hierarchy - Components with consistent styles and interaction states - Patterns for responsive behavior - Accessibility guidance and tested component behavior - Application layouts and page templates - Documentation explaining how to combine everything Starting with these elements raises the baseline quality of every screen we build. A design system cannot guarantee a good user experience or give us a finished product, but it makes common problems with consistency, readability, responsiveness, and interaction less likely while letting us focus on the information and workflows specific to our product. How this changed the way one team worked I saw the difference firsthand on a product team I worked with. We started without a design system. As the application grew, interface development became slower, inconsistencies accumulated, and users encountered more UI bugs. We eventually adopted Untitled UI and worked with a designer who could only spend limited time with the team. Even with that constraint, we redesigned and implemented the application's entire interface in two weeks. The design system gave us a shared foundation. The designer could spend more time improving workflows and information hierarchy, while we could implement those decisions using components and rules that already worked together. The result was not only faster development. We also considerably improved the consistency and usability of the product. If this approach is so fast, what do we give up? A common concern is that using an existing design system will make the application look generic or disconnected from its brand. Some similarity between applications is not only unavoidable but desirable. Products within the same category often share a structure because users already understand how that structure works. Consider WhatsApp, Signal, and Telegram. They all present a list of conversations, open each one into a message thread, distinguish between incoming and outgoing messages, and place the message composer near the bottom of the screen. Different visual identities, familiar messaging patterns. Screenshots from the official App Store listings for WhatsApp, Signal, and Telegram. Someone who knows how to use one of these applications can understand the others without learning a completely new interaction model. Changing familiar patterns simply to look different would probably make the product harder to use. Following familiar patterns does not mean giving up the product's identity. We can express its brand through: - The logo and product marks - A brand-based accent color with variants for different states and levels of emphasis - Typography - Images and illustrations - Tone and microcopy The goal is not to make the application look unlike every other application. It is to make it recognizable as our product while keeping the patterns that help people understand how to use it. How I choose a design system I start by listing the screens and workflows the product needs. A dashboard with tables, filters, forms, and complex navigation requires a different foundation from a simple content application. I look for a system that provides: - The components required by the product's main workflows - Application layouts and page templates - Accessible interaction states and sensible defaults - Enough flexibility to reflect the brand - Clear documentation and practical examples - Support for the project's technology stack - Evidence that it is actively maintained Application templates become especially valuable when they cover the same domain as the product. If we are building a messaging product and the system includes a chat application, we can adapt an established structure instead of assembling every screen from scratch. I have used HeroUI and Untitled UI, and I consider both good options. Their free versions provide components, while their paid versions offer access to more complete collections and application examples. Paying for one can be a sensible investment if it saves several days of design and development work. If paying is not an option, Astryx is open source under the MIT license and includes components, themes, patterns, and application templates. I have not used it in a real project, so I cannot personally vouch for it, but it looks solid from my initial review. It is also currently in beta, which is worth considering before using it in production. Design systems help AI tools and designers work more effectively When we ask Claude or Codex to design an interface from scratch, they often produce a screen that looks convincing at first glance but does not work well as part of a real application. The interface may have weak visual hierarchy, overlook important states, behave poorly on smaller screens, or introduce accessibility problems. The tool also invents foundational decisions as it works, causing those decisions to drift between screens. A design system gives the AI tool a defined language. We can give it access to the documentation, including a DESIGN.md file written for coding agents when one is available, and instruct it to use the existing components and patterns. The tool can then focus on arranging the interface around the user's task instead of inventing its foundations. One useful thing I do within those constraints is ask AI to create several versions of a screen using the same system, then compare how each version organizes information, actions, and navigation. The same foundation makes working with designers more efficient. A designer who joins the project or has limited time does not need to begin by rebuilding the basics. They can focus on workflows, information hierarchy, and problems specific to the product and its users. A design system does not replace design knowledge or a good product designer. It gives developers, AI tools, and designers a shared starting point. From a product idea to a branded interface Let's see what this approach looks like in practice. For this example, I will use Astryx to build a screen for a fictional product. I chose Astryx because it is open source and available to anyone following the example, not because I consider it the most mature option. The product is Canopy, a planning application for habitat-restoration teams. It helps teams organize work such as surveying sites, preparing planting zones, coordinating crews, and reviewing completed field work. A Kanban board gives those teams a familiar way to track work from planning to completion. Fortunately, Astryx includes a Kanban template with most of what we need, including the board structure, task cards, and drag-and-drop interactions. The default Astryx Kanban template. In a real product, we would probably change some of the template's functionality. For this example, we will assume the features are sufficient and focus on making the interface feel more consistent with Canopy's brand. I wanted Canopy to feel calm, practical, and connected to the natural environments where restoration teams work. Astryx includes several themes, and Matcha's earthy palette came closest to that direction. I designed a logo and added it to the screen. I also replaced the theme's handwritten heading typeface with Figtree because I found the original hard to read. Figtree is easier to read while preserving the friendly tone I wanted for Canopy. I changed the developer-controlled microcopy to use language restoration teams would recognize, including Planned, Awaiting review, and Add field task. Finally, I added a custom empty-state icon because empty states offer a natural place to express more of the brand. Each change is small, but together they move the interface away from Astryx's default configuration and give it more of Canopy's identity. The same template adapted for Canopy. Starting with Astryx allowed us to move directly from the product idea to shaping the interface. The template gave us a coherent Kanban board that would have taken much longer to design and build ourselves, while leaving enough flexibility to introduce Canopy's brand identity. Under the same time constraints, most developers would struggle to produce something this complete and polished from scratch. The value of the design system does not end with this screen. Whenever Canopy needs a new feature, we can return to its components, patterns, and templates. Even when a template does not exist, the design system still gives us leverage. We can study products with similar functionality, identify how they organize information and actions, and rebuild those useful patterns using our system. Putting it all together When I need to build a solid interface quickly without regular design support, I follow f