IMS is the internal platform Nasdaq uses to manage the lifecycle of every financial index in its portfolio — from initial research and approval through ongoing rebalances, reconstitutions, and compliance attestations. It serves index portfolio managers, operations analysts, launch coordinators, and compliance teams. Every index Nasdaq publishes — hundreds of them, tracking trillions in assets — flows through this system.
IMS had been built sprint by sprint for years — every screen a direct response to a feature request, never to a user need. There was no research practice, no design system, no shared visual language, and no structured feedback loop. The result: dense forms with no hierarchy, a navigation structure that reflected internal team vocabulary rather than user tasks, and an application that Nasdaq — a company that takes its brand seriously — would never have shipped externally.
The response wasn't to start making screens prettier. A formal design strategy was developed and presented to Nasdaq stakeholders — a structured proposal for how to introduce design maturity into a project that had never had it. The strategy was accepted and became the operating framework for the next two years of product evolution.
Structured discovery sessions, workflow shadowing, and stakeholder interviews produced a set of user personas that became the foundation for every design decision — documenting who the analysts were, how they spent their time, what frustrated them, and what they actually needed the system to do.
The first design deliverable wasn't a screen — it was a sitemap. IMS had grown organically for years, with navigation reflecting internal team vocabulary rather than user tasks. The IA overhaul renamed, consolidated, and restructured every section of the application into 8 clear primary areas before a single interface was redesigned.
The Index Inventory was the main entry point to IMS — and in the original system, it was a flat searchable table with no summary metrics and no way to understand the portfolio at a glance. The redesign added a contextual sidebar with quick actions, a KPI strip surfacing the most important numbers, and a table that could be filtered and customized without leaving the page.
The Index Record is where analysts spend most of their day — reviewing evaluation schedules, tracking rebalance and reconstitution details, managing team assignments, and monitoring outstanding tasks. The redesign replaced a flat form-heavy layout with a structured two-panel view: a persistent sidebar for contextual information and a tabbed main panel for deep content navigation.
MQA's legacy system — LEIDS — had accumulated decades of workarounds. Processors managed PDF checklists stored locally on their desktops. Applicants had no visibility into where their application stood. Deficiencies were communicated by phone and letter. Everything needed to be rethought.
Before any interface work, the team mapped every process end to end. 49 parent processes. 194 subprocesses. Two full rounds of stakeholder review documented in a living BPR matrix. Every design decision traced back to a business need, a statutory requirement, or a documented user pain point.
Before designing anything, the team defined the outcomes they were optimizing for — a design philosophy applied to government operations.
The processor queue replaced a flat list of 500+ records with role-based tabs, deadline-coded rows, and KPI cards that surface what needs attention before a processor has to look for it.
The LEIDS license record was a flat field dump — every piece of data equally weighted, no hierarchy, no task context. HELIX replaced it with a structured two-panel view: a live deficiency checklist on one side, a processing clock against the statutory deadline on the other, and a complete audit trail — all without navigating away.
The Civil Service Commission (CSC) application was nearly complete. Then came the requirement to deploy the same application — same structure, same logic, same object count — across three additional state departments, each with different group names, different UUIDs, different folder structures, and different data schemas.
Manual rebuilding was off the table. Cloning and editing 800+ Appian objects one by one would take months and introduce errors at every step. The problem wasn't development — it was transformation at scale.
Every Appian object — processes, interfaces, records, data structures — was structurally identical between departments. Only the identifiers changed: group names, UUIDs, folder references, data source names. That's not something you solve by writing code. That's something you solve by writing instructions for Claude Code to execute.
The insight was treating the entire application as a structured document to be transformed, not a codebase to be rewritten. Claude Code reads the source XML, applies a mapping config, validates the output, and packages it for deployment — automatically, repeatably, for any department.
Each stage has a single responsibility. The pipeline is Claude Code orchestrating itself against a structured config — no custom scripts, no brittle regex, no manual intervention.
This is the actual Claude Code prompt used to trigger a standard department transformation. One prompt. One pipeline run. One deployable package.
Most bird apps are built for people who already know what they saw. You search by name, browse a field guide, confirm an ID. But real birding is messier — you caught a glimpse, heard a sound through the trees, or saw a flash of color and need to work backwards from a description. No existing app was built for the moment of uncertainty.
The core design insight: identification should start with what you have, not what you should have. A photo? Great. A song? Perfect. Just a rough description of a bird you saw in your backyard? Also great. Birdseye is built to work with incomplete information — because that's what birding actually gives you.
The core of the app. Three input modes unified under a single tab — Camera, Sound, and Describe. The AI reads whatever you give it and narrows the possibilities down to a confident match.
Each mode solves a different version of the same problem. The design challenge was making them feel unified — same tab, same screen, just different inputs — without making any single mode feel secondary.
Search or browse species filtered by type — Songbirds, Raptors, Waterfowl. Each species card shows the AI match percentage from your last sighting. Species you've added to your life list get a checkmark. The field guide is aware of your history.
My Lists is your life list — every species ever identified, numbered in order of discovery, with location and date. Filterable by Life List, year, and Trips. The Map plots those same sightings geographically, clustered by density, filterable by Week / Month / Year / All Time.
Profile surfaces what makes each birder's journey unique — life list count, total sightings, countries birded, rarest find. Achievements (Raptor Watch, Early Birder, Explorer) unlock based on real behavior, not arbitrary gamification. A weekly activity chart keeps the streak visible.
The app's appearance adapts to the user's chosen bird species theme. Each theme is a complete, cohesive color system — not just an accent swap. Mallard is the default (forest green & amber). Users unlock Robin and Bluebird based on their sighting history.
