It started the way all great tech adventures do: with a painfully early alarm. Waking up before 4 to catch a flight to London. Together with a colleague we were enlisted to join a two-day, intensive Sigma training, and by the time we landed, we were ready to dive into the world of application design.
The energy in the room was high, largely thanks to Donny Alfano from Sigma HQ in San Francisco. Watching Donny explain the mechanics of Sigma while effortlessly building a fully functional Expense App was both inspiring and a little daunting. Following along felt like sprinting just to keep pace, but it perfectly set the stage for the real challenge: getting our own hands dirty building an app within Sigma.
Our goal for the breakouts was ambitious. We wanted to design a "Sigma AI" app to manage the bench at DDBM. Turning the administrative task of matching unassigned consultants to project roles into a dynamic, visual simulation. To get there, we had to rely on two massive frameworks we learned during the training.
Here are the most useful insights and technical structures we took away from those two days.
The Blueprint: The BUILD Method
You cannot just start throwing charts on a canvas and call it an app. To keep our breakouts focused, we leaned heavily on the BUILD method. At a high level, BUILD breaks application design down into five core components:
- B — Business Objective: What problem are we actually trying to solve? (For us, it was getting people off the bench and onto great projects).
- U — User Workflow: How does the user step through the app from start to finish?
- I — Input Model: How is data entering the system?
- L — Look & Feel: Defining the zones, containers, and brand tone before building.
- D — Development Cycle: The actual iterative process of putting it all together.
The Engine: Tabbed Containers for Apps
The biggest paradigm shift was understanding the structural difference between standard workbooks and interactive apps. Because apps rely on user interactivity, the underlying data structure requires a specific tabbed container layout.
Here is the exact framework we used to keep our data clean and scalable:
1. Input Tables The shift from raw tables to input tables is the defining difference between apps and workbooks. These are custom-created, predetermined by the developer, and are the exact places where the end user edits data via pop-ups, modals, forms, and filters.
Pro Tip: Always ensure your field types are strictly defined, populate your drop-downs with appropriate validation, and create at least three rows of dummy data for immediate testing.
2. Base Tables These are the child elements of your input tables. As the user adds data (like submitting an expense or assigning a consultant), the base tables automatically update. Crucially, this is where your visualisations should be drawn from, not directly from the input tables.
3. Control Tab This operates the same way it does in a standard workbook, housing both page controls and control tables. For clarity and easier handovers, it is best practice to keep your control inside a container right next to the specific control table it filters.
4. Reference Tables Finally, the reference tab is your enrichment zone. This holds all the static or semi-static tables used for joins and lookups (like our underlying Projects or Consultants data) to give the app its context.
Result: Taking the abundance of information, tips and tricks into Sigma moving forward
We were able to create the start of this App in 1 day of frantic working and presenting our results back to the group. Flying back home after those two days, my brain was entirely fried, but the architecture of how to build interactive, data-driven applications in Sigma finally clicked. We walked in with a vague idea for a bench management tool, and we walked out with a concrete BUILD strategy and a rock-solid data model. As more Sigma work comes across our desk, internally and for clients, we now have not only a beautiful app that we can create but with legible structure and a successful way of working.
