A website is visited. A product is used. The two require different kinds of thinking. This page is about the second one. Product design, user flows, dashboards, and SaaS interfaces for teams who are building something that has to work on day 180, not just on launch day.
Let's Talk
A lot of agencies blur the line between visual design and product design. We keep the line bright. Visual design is about how the thing looks. Product design is about how the thing works. Both matter. They are not the same discipline.
UI UX at Creative Dady is product design. It starts with a research phase. Who uses this. What are they trying to accomplish. Where do they get stuck in the current flow. What task do they do ten times a day and what task do they do once a month. The answers to those questions shape every screen we draw, because a screen designed without those answers is a screen designed for nobody.
We study Interaction Design Foundation material on interaction patterns and accessibility because the fundamentals matter and they are not optional just because a team is moving fast. We study the way Linear, Notion, Figma, Stripe, and Raycast handle the small moments in their products because those small moments are where the craft shows. And we apply what we learn to the work we do for our clients.
Every UI UX engagement starts with a discovery phase. We sit with the client team and map the product as it exists today. We identify the two or three flows that matter most to the business. We talk to users if the client can make that happen, and if not, we work from session recordings, support tickets, and analytics. We come out of discovery with a document that says, in plain English, what the product is trying to do and where it is currently falling short.
Then we design. We start with low-fidelity wireframes because the wrong time to argue about colors is when you are still arguing about flows. We iterate the flows with the client in real time, over shared Figma sessions, until everyone agrees that the skeleton is right. Only then do we start layering visuals on top.
After the visual round, we prototype. We build clickable Figma prototypes that the client can hand to a real user and watch them try to use. We sit in on the sessions when we can. The feedback from the first user test usually forces us to rework something, which is the feedback loop working the way it is supposed to. By the time we hand over to the development team, the flow has been stress-tested against real humans, not just the founder and the design team.
A Figma file containing the production-ready screens, grouped by flow. A component library with every interactive state drawn out, including empty states, loading states, error states, and success states. A prototype that demonstrates the critical flows end to end. A short design document that explains the reasoning behind every non-obvious decision, because the development team that builds it and the product manager who maintains it both deserve that reasoning.
p>What they do not receive. Pixel-perfect static mockups with no thought put into the states nobody wants to think about. A deck full of user personas that have no bearing on any decision. A heat map generated from a focus group of six people. The deliverables are what you will actually use, not what will look good in a pitch deck.
Early-stage SaaS products that need the first usable version of the interface. Existing SaaS products that are being redesigned because the original version was built without a designer and has outgrown itself. Internal tools and dashboards that the company has been shipping on Bootstrap for three years and is finally ready to treat as a real product. Onboarding flows for products where the activation rate is the metric the founder cannot sleep about. Mobile app flows where the design and development teams need a unified source of truth.
We say no to enterprise suite design, because that calls for a team of six product designers, not a studio like ours. We say no to projects where the brief is "just make it look pretty," because UI UX is not a paint job, and hiring us to do UI UX work and then refusing to let us run research is hiring the wrong studio. We say no to projects without a clear single decision maker on the client side, because design by committee is the slowest way to ship mediocre work.
A lot of our UI UX work is for companies that already have a product team. A founder, a product manager, one or two engineers, maybe a first designer who is stretched thin. We fit into that team, we do not try to replace it. We run design sprints, we hand over finished screens, we join the standups during the active phase, and we step back when our part is done. The engineers keep writing the code. The PM keeps running the roadmap. We show up when design is the bottleneck and we leave when it is not.
This model works because we are honest about our limitations. We are a small studio. We do not want to be your in-house team. We want to be the specialist you call in when the work needs a standard your team is too busy to hold.
Tell us about the product. What it does. Who uses it. What you are trying to fix or launch. If you have analytics, send a screenshot. If you have user interview recordings, even better. If you just have an idea and a deadline, that is fine too, we have worked from less.
Start a Project →