DDBM Blog

Onze 2-daagse Sigma Training in Londen

Geschreven door Wouter Martens | 22 May, 2026

Zoals bijna alle geweldige tech-avonturen begon ook deze met een zeer vroege wekker. Om 5 uur 's ochtends stonden we op om een vlucht naar Londen te halen. Met twee man van DDBM waren we ingeschreven voor een tweedaagse, intensieve Sigma-training. Nadat we geland waren reden we met de trein richting London centrum. Toen we aankwamen bij het kantoor van Sigma waren we er helemaal klaar voor om de wereld van applicatieontwerp in te duiken.

De energie in de zaal was hoog, grotendeels te danken aan Donny Alfano van Sigma uit San Francisco. Volgen hoe Donny de werking van Sigma uitlegde terwijl hij moeiteloos een volledig functionele Expense App bouwde, was zowel inspirerend als een beetje intimiderend. De app nabouwen tijdens de uitleg voelde als een sprint om het tempo bij te houden, maar het vormde de perfecte basis voor de echte uitdaging: zelf de handen uit de mouwen steken om een app te bouwen binnen Sigma.

Ons doel voor de break-out sessies was ambitieus. We wilden een "Sigma AI"-app ontwerpen om de bench (reservebank) bij DDBM te beheren. De administratieve taak om niet-toegewezen consultants aan projectrollen te koppelen, wilden we omzetten in een dynamische, visuele simulatie. Om dat voor elkaar te krijgen, bouwden we voort op twee grote frameworks uit de training. Hier zijn de nuttigste inzichten en technische structuren die we uit die twee frameworks hebben meegenomen.

De Blauwdruk: De BUILD-methode

Je kunt niet zomaar wat grafieken op een canvas gooien en het een app noemen. Om onze break-out sessies gefocust te houden, leunden we zwaar op de BUILD-methode. Op hoofdlijnen deelt BUILD het ontwerpen van applicaties op in vijf kerncomponenten:

  • B — Business Objective (Zakelijk Doel): Welk probleem proberen we eigenlijk op te lossen? (Voor ons was dat: mensen van de bank halen en op geweldige projecten plaatsen).
  • U — User Workflow (Gebruikersstroom): Hoe doorloopt de gebruiker de app van begin tot eind?
  • I — Input Model (Invoermodel): Hoe komt data het systeem binnen?
  • L — Look & Feel (Uitstraling): Het definiëren van de zones, containers en de merkbeleving voordat je gaat bouwen.
  • D — Development Cycle (Ontwikkelingscyclus): Het daadwerkelijke iteratieve proces om alles samen te voegen.

De Motor: Tabbed Containers voor Apps

De grootste omslag in ons denken was het begrijpen van het structurele verschil tussen standaard workbooks en interactieve apps. Omdat apps afhankelijk zijn van gebruiker interactiviteit, vereist de onderliggende datastructuur een specifieke lay-out met tabbed containers (containers met tabbladen).

Dit is het exacte framework dat we hebben gebruikt om onze data overzichtelijk en schaalbaar te houden:

1. Input Tables (Invoertabellen) De verschuiving van ruwe tabellen naar invoertabellen is het bepalende verschil tussen apps en workbooks. Deze zijn op maat gemaakt, vooraf bepaald door de ontwikkelaar, en het zijn de exacte plekken waar de eindgebruiker data bewerkt via pop-ups, modals, formulieren en filters.

Pro Tip: Zorg er altijd voor dat je veldtypes strikt gedefinieerd zijn, vul je dropdowns met de juiste validatie en creëer minstens drie rijen met dummy-data om direct te kunnen testen.

2. Base Tables (Basistabellen) Dit zijn de onderliggende elementen van je invoertabellen. Zodra de gebruiker data toevoegt (zoals het indienen van een declaratie of het toewijzen van een consultant), worden de basistabellen automatisch bijgewerkt. Cruciaal: op deze tabellen worden de visualisaties aangesloten, en niet direct op de invoertabellen.

3. Control Tab (Bedieningstabblad) Dit werkt op dezelfde manier als in een standaard workbook en bevat zowel pagina bedieningen (page controls) als besturings tabellen (control tables). Voor de duidelijkheid en een eenvoudige overdracht is het een best practice om je bediening in een container te plaatsen, direct naast de specifieke besturingstabel die ermee gefilterd wordt.

4. Reference Tables (Referentietabellen) Tot slot is er het referentie tabblad. Hier kan je data plaatsen om de andere tabellen te verrijken. Hierin staan alle statische of semi-statische tabellen die worden gebruikt voor joins en lookups (zoals onze onderliggende Projecten- of Consultants-data) om de app zijn context te geven.

Het is ons gelukt om de basis voor deze App in één dag van hectisch werken in elkaar te zetten. Daarnaast presenteerden we onze resultaten aan de groep en hadden andere groepjes ook soortgelijke apps gebouwd.

Toen we na die twee dagen terug vlogen, waren onze hersenen nog in overdrive, maar de architectuur van het bouwen van interactieve, datagedreven applicaties in Sigma was eindelijk op zijn plek gevallen. We kwamen binnen met een vaag idee waartoe Sigma in staat was. We hebben geleerd dat er nog veel meer mogelijkheden zijn dan het standaard visualiseren van data. In Sigma zijn hele apps te bouwen die voor elk bedrijf van meerwaarde kunnen zijn.