Before we could design anything, we had to understand how Chat apps actually worked under the hood. Our first task was to build a simple app in code ourselves — walking through the same process developers go through to ship one. It was basic, but it meant that every design decision we made after that was grounded in how these apps actually get built and deployed.

Google Chat had an existing ecosystem of third-party apps. We audited what was already out there, mapped the patterns that worked and the ones that didn't, and started building a mental model of where the real friction lived. That meant a lot of conversations with the dev team — not just "can we do this?" but "why does it work this way?" and "what are we actually constrained by?"

The first two apps were our proving ground. We used them to figure out what a repeatable process looked like for this kind of work — benchmarking, flow design, sketches, wireframing, and design specs — and then locked that process in for the remaining five. Having a consistent framework meant we could move fast without rethinking our approach every time a new app came in. The process itself became a deliverable.

Every app meant a new domain. Bitbucket thinks in repositories and pull requests. Asana thinks in tasks and timelines. Calendar thinks in availability and conflicts. We had to learn each platform's logic well enough to prioritize the right actions and surface the right information inside Chat — which meant reading API documentation, mapping data structures, and genuinely understanding how developers, project managers, and everyday users each think about their tools differently.

The design system for third-party apps was minimal. A small set of components with hard technical constraints on layout and interaction. That limitation turned into one of the most interesting design challenges of the project. We found ways to repurpose the same components for different functions, stretch visual hierarchy with the few tools we had, and make apps feel distinct from each other while working within identical constraints. Some of our most creative solutions came from having almost nothing to work with.

Seven apps across platforms with completely different user bases and workflows. From developer tools like Bitbucket and Jira, to project management with Asana. Each one was a full cycle: research the platform, understand the users, design within constraints, spec for development. We shipped the Bitbucket app and ran QA on it during the engagement. The YouTube app came from a different place. Between projects, we were invited to propose an integration if we saw a good opportunity. We pitched a music recommendation feature tied to listening history, and built it out.