Yally.Ai -
Your Digital
Headquarters.

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.

Client
Inclusive Financial Solutions (IFS)
Region
Saudi ArabiaSaudi Arabia · Global
Industry
AI / Business Management / SaaS
Scope
Web · Mobile · Enterprise White-Label · Design System
Fig. 01 — Yally.Ai

Snapshot

Role
Lead Product Designer, solo, end-to-end
Team
CEO, CTO, Business Analyst, Product Manager, Front-End and Back-End Developers; early-access customers
Timeline
4 months to MVP (ongoing; now post-MVP)
Platform
Web app (with a companion mobile app, collaborated on)
What was mine
Information architecture, all design execution, the design system, and the brand, owned solo. Product concept and direction were set by the CEO and business analyst; I owned how it was structured, how it worked, and how it looked.
Overview

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.

Fig. 02 — Organization dashboard · KPI widgets
Context

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.

My Role

A solo design engagement, end-to-end.

  • Mine: Information architecture for the entire system, all design execution across every module and flow, the design system, and the branding. Every screen, pattern, and interaction in the MVP.
  • Shared: Product concept and direction were set with the CEO and business analyst. I worked closely with the product manager and the developers through build, and collaborated on the companion mobile app.
  • Set by others: The vision and feature scope.

The honest split: leadership owned what Yally should be, and I owned how it works, how it's organized, and how it looks.

Fig. 03 — Overview · the AI-first landing for executives
The Problem

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.

Fig. 04 — Inside a space · nested modules
Fig. 05 — Spaces' map & list view
Approach & Success

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.

Process & Exploration

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.

Fig. 06 — Inbox module · internal inbox & external emails
Fig. 07 — Calendar module · meeting intelligence
The Solution

A single environment spanning the full lifecycle of work, from first sign-in to enterprise-grade administration.

  • Onboarding and access. Sign-up, verification, payment, KYC, system configuration or delegation, a guided simulation, AI-assisted file upload that seeds the knowledge base from day one, and member invitation.
  • Spaces. The organizing primitive, containing subspaces, projects, teams, folders, and documents, with rich creation flows and universal appearance controls and presets across header, list, card, and tree views.
  • Views. Expandable list, card, and tree views for a deeply nested system, each surfacing which layer you're in.
  • Projects. Task board, progress tracking, analytics, attachments, and full task management with comments and subtasks.
  • Teams. Everything tied to a team in one place, with membership, KPIs, and analytics.
  • Documents and folders. Nested folders, a full document editor, and global and private documents across multiple views.
  • Per-space communication. Space-scoped chat, calendar, emails, notifications, and AI insights.
  • Calendar. Day, week, and month views, event creation, meeting intelligence, and Google Calendar and Teams connections.
  • AI, woven throughout. System-wide AI chat with selectable service and history, plus a dedicated AI insights landing experience.
  • Personal and team dashboards. A landing overview, a personal dashboard, and a team performance dashboard searchable by user or team.
  • Organization dashboard. A widget library of industry-standard KPIs I designed; users assemble their own view, edit widgets, and choose each source from the knowledge base.
  • KPI builder. Industry-standard templates plus a custom builder supporting manual and AI-assisted creation.
  • Workflow system. A full builder for modeling an organization's own processes.
  • Compliance. Usage monitoring, rules database, rule builder, violations, and analytics by team or user.
  • Inbox. Unified internal and external communication, connecting external email alongside the system inbox.
  • Admin panel. Space and user management, roles and permissions, guest management, AI configuration, knowledge base, deletion flows, usage breakdowns, billing, security, and branding.
  • Guest experience. A dedicated view for limited external access.
  • Enterprise white-label (Blacksuite). A re-brandable tier with a company's own branding, colors, logos, and DNS.

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.

Fig. 08 — Projects · kanban board
Fig. 09 — Teams · workload & performance
Fig. 10 — AI · context-aware assistant
Fig. 11 — Overview · personal dashboard & AI insights
Key Decisions & Tradeoffs
01
One creation pattern, adapted per module.
Every module that creates something (space, subspace, project, etc.) uses the same pattern, a split view of information and appearance, fitted to its needs.
Tradeoff: each flow could have been hand-tailored, but a shared pattern means a user learns creation once and it transfers everywhere.
02
AI woven in via a persistent, context-aware bar.
The AI co-leader concept was the CEO's; making "AI everywhere" usable rather than overwhelming was the design problem, and mine. The answer is a persistent AI bar with quick actions, context-aware to wherever it's opened: launch it in the "Marketing" space and it surfaces insights for that space, with one tap to widen system-wide.
Tradeoff: a single global chatbot would have been simpler, but it would have contradicted the product's reason to exist.
03
Design system and brand built first, as the foundation.
I designed both up front, before building modules out.
Tradeoff: on a four-month MVP, investing in a system before shipping visible screens is slower at the start, but for a solo designer covering this many modules it was the only way the product could cohere, and it's what later made the white-label tier possible.
04
One unified admin layer instead of scattered settings.
Yally's control surface is enormous, so I designed it as one coherent admin panel rather than letting each module carry its own settings.
Tradeoff: centralizing this much control is harder to structure than sprinkling settings where they're used, but it gives admins a single, predictable place to run the organization.
05
Per-space identity without breaking the system.
Each space can carry its own look and feel so teams feel ownership, while subspaces inherit a parent's identity.
Tradeoff: this much customization risks the system fragmenting visually, the exact thing the product exists to prevent. Universal appearance controls and presets let personalization and coherence coexist.
Fig. 12 — Admin · one unified control layer
Fig. 13 — Admin · plans & billing
Fig. 14 — Approval center for management
Fig. 15 — AI configuration · prompt builder
Fig. 16 — KPI builder · guided creation
Impact & Results

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:

  • Shipped design, in full, in four months. A complete MVP across more than a dozen interconnected modules, designed solo, reached live status on a tight timeline.
  • Coherence held at scale. Despite the breadth, the system reads as one product, continuous from onboarding to admin.
  • Early customers found it usable. The core idea resonated and the system was received as easy to use, the central design goal, even with its large surface area.
  • The foundation is carrying the next phase. The design system is letting the product extend into post-MVP work and a white-label tier without coming apart.
What's Next

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.