Solo-designed the end-to-end product, design system, and brand for Yally.Ai, an AI-native work operating system that unifies a dozen-plus modules (spaces, projects, documents, calendar, compliance, admin, and more) into one continuous flow. Shipped the MVP in four months; now in post-MVP.
Yally.Ai is an intelligent work operating system: a single environment that connects a company's work, decisions, and knowledge instead of scattering them across meetings, chats, and disconnected tools. It spans projects, spaces, documents, calendar, inbox, compliance, a full admin layer, and an AI co-leader woven through all of it.
I joined as the sole designer to take that concept from idea to working product. Over four months I built the information architecture, the design system, the brand, and every flow across the MVP. The core challenge wasn't any single module; it was making a dozen-plus modules feel like one coherent system with one continuous flow, rather than a suite of separate tools sharing a login.
Yally.Ai is built on a simple observation: decisions live in meetings, context disappears in chat threads, and organizational knowledge resets every time a team changes. Work is fragmented across tools that don't talk to each other, and the reasoning behind decisions evaporates.
Yally's answer is to be the shared operating layer, where tasks, decisions, and knowledge connect and compound over time, with an AI co-leader giving teams the visibility to act earlier and align faster. It's aimed at organizations from individual teams up to enterprises, including a white-label tier for companies that want to run Yally under their own brand. For a product whose premise is removing fragmentation, the design itself had to feel unfragmented, which made coherence the central design problem rather than a finishing touch.
A solo design engagement, end-to-end.
The honest split: leadership owned what Yally should be, and I owned how it works, how it's organized, and how it looks.
What people struggle with. Teams lose the thread of their own work. The task is in one tool, the decision behind it in a meeting nobody recorded, the context in a chat that's scrolled away, the institutional knowledge in the head of someone who left. Reassembling that picture across tools is constant overhead.
How I framed the design problem. The concept solved fragmentation at the feature level: put everything in one place. But that creates a harder problem at the design level, because a single product containing a dozen-plus powerful modules can itself feel fragmented if each behaves like its own app. The question I set out to answer: how do you make a system this broad feel like one continuous, learnable, navigable environment, instead of twelve tools wearing the same logo? That framing drove nearly every decision below.
Discovery wasn't front-loaded. The concept and module scope arrived largely defined by leadership, and the timeline was tight, so the early work was less open-ended research and more rapidly building a workable architecture from a complex brief. Once the MVP was live, I gathered feedback from early-access customers and adjusted parts of the system in response, directional and broadly validating input that now feeds the post-MVP phase rather than having reshaped the MVP's foundations.
As an early-stage product, success was defined by design quality and adoption readiness rather than performance metrics that didn't exist yet. The targets were coherence (the system should read as one product no matter how many modules it holds), learnability (learning one part should teach the rest), navigable depth (a user should always know where they are), and a scalable foundation able to grow and re-skin into a white-label tier. There are no hard performance numbers yet; the product is early and I don't own its analytics. "Good" was judged by whether the system held together as it grew and whether early customers could use it without hand-holding. On those terms, the MVP met its goals.
The hard part of Yally was never any individual screen. It was the architecture: deciding what lives where, how modules relate, and how a user keeps their bearings inside a system this deep.
Keeping users oriented in a deeply nested system. Early on this was a genuine failure point: users got lost, unsure which level they were on or how the thing in front of them related to the rest. The feedback was clear, and the fix was to stop relying on navigation alone and make depth visible. The system now signals where you are through layered cues working together: cover photos that identify a space at a glance, a distinct nested visual style for the sub-modules inside a space, and tree (canvas) and list views that expose the hierarchy directly. Orientation became a property of how the system looks, not something the user has to reconstruct.
Deciding what's scoped to a space versus what's global. Some things belong inside a space because they're the structure of the work itself: subspaces, projects, teams, folders, documents. AI sits at the core level, beneath everything. And a set of capabilities, inbox, calendar, email, AI, exist as first-class modules at the system level and connect into individual spaces. Drawing that line, structural things nest inside spaces while capability modules live globally and reach in, kept the system from collapsing into either a pile of disconnected tools or one undifferentiated blob.
Designing the connective tissue between global modules and spaces. Once a capability like inbox lives globally but serves specific spaces, the design problem becomes the connection, not the module. The inbox isn't just a mailbox; it lets a user connect external email to a particular space, or build a rule so incoming mail matching certain words or senders routes itself to the right space automatically. The same logic runs through calendar and AI. This is what makes Yally feel like one system rather than a launcher for twelve: the modules don't just coexist, they wire into the structure of the work.
Onboarding a system this large without overwhelming a first-time user. Onboarding includes a simulation: a button that populates the system with sample data so a new user can see everything working in context, guided by tooltips, and exit at any time. Rather than explaining the system abstractly or dropping the user into an empty shell, it lets them learn by exploring a system that's already alive.
A single environment spanning the full lifecycle of work, from first sign-in to enterprise-grade administration.
The connective tissue across all of it is a shared component system and consistent interaction logic, so that despite the breadth, the system reads as one product.
The product is early and I don't own its analytics, so there are no hard performance numbers yet, and inventing them would undercut everything else. What I can speak to is real:
The work is ongoing. The post-MVP phase is incorporating early-customer feedback and extending the system, with the design-system foundation doing exactly what it was built to do: letting the product grow without losing the coherence that defines it.