Getting out of the deliverables business

Once upon a time, there was a marketing person with great ideas for a new software application.

He hired a business analyst, who described all those ideas in formal specifications fully documented business requirements (including use-cases, business rules, exceptions …). This deliverable was handed over to a User Interface / User Experience expert who created a detailed User Interface (including wireframes, site maps, screen flows, mock-ups,…) and described all the user interactions. Next, a functional analyst translated those requirements to an available specification and tried to figure out how to connect them to existing infrastructure and systems.

Given the functional specification, a technical analyst created a technical specification and application design to capture all the given information in a deliverable that would make sense as input for development. Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect graphic designs for every screen of the application. A copywriter was sometimes assigned to write on-screen text labels and copy based on the wireframes. And even sometime later, a tester was given the assignment to understand the requirements and write test scenarios.

Development was about to get started!

Sometime later, during development, some concerns arose about the application’s User Interface, and a usability engineer reviewed the User Interface specification to give some advice and remarks.

So, what do we observe?

  • The work goes sequential
  • Individuals doing their own thing, producing output: deliverables, documents!
  • Time passes by
  • Handoffs, with potential gaps for misunderstandings, misalignments, information lost in translation

Let’s retrospect.

Silo teams

The goal was to create a new software application – with probably a fantastic idea in my mind and initiated by a great business case. Where is our software?

Focus on outputs, not outcomes. People are appreciated for their output: mainly documents and the quality of those documents.

Those documents are written by an individual or a group of individuals of the same expertise – documents are passed on (with or without explanation). The output of one phase is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each needs to re-interpret the previous work—no real sense of ownership.

It’s a very time-consuming process. From inception to the actual start of development, it can take months – depending upon the size of the project.

Assumptions, lots of assumptions! Hypotheses based on those assumptions. As great as it might be, a requirement spoken by the guy from marketing remains an assumption until proven by the market: feedback from actual end-users: the customer.

There is little to no opportunity to react and correct the design of the new software application when new insights or market conditions come up meanwhile developing.

Probably the whole process is overseen and controlled by a commanding officer.

Where’s our marketing person? Out of sight

A chain is only as strong as its weakest link.

Teams used to a sequential process have become accustomed to handoffs between specialists. Each group passes off their work to the next group. These handoffs include overhead in meetings, documents to review and approve, waiting time, etc. Anything that does not directly contribute to the project’s goal: creating software is waste.

Let’s reconsider.

Once upon a time, a marketing person had a great idea for a new software application.

The sponsor gathered a team with expertise in IA/UI/UX, usability, customer engagement, front-end/back-end development and testing. The team formulated the new application’s business goal and desired business outcome with the marketing guy. Together, the team made this set of skills, not an individual, for each required expertise.

The team focused on the outcomes that would address the primary customer need of our application. The idea was conceptualised lightweight: the team formulated some hypotheses: valuable features that they considered a good collection for a ‘minimum viable product’ and a set of metrics to verify those hypotheses. Next, the team draw some UI sketches on paper. The team set out a test by linking the UI sketches to an “interactive” prototype for internal validation. Considering the received feedback, the team refined that small set of features to a user story level with the main acceptance criteria.

The team decided to prototype directly in HTML/CSS as this was the preference of the web developers. The team organised a user test with key customers and external (non-customer) people. These tests and the earlier defined metrics concluded and prioritised several improvements. Collectively, the team came up with the adaptations. With minimum documentation effort (again: main wireframes and a list of agreed-upon decisions), They improved the prototype and discussed a subsequent set of functionality.

Meanwhile, the needed services were encoded and deployed to connect the front-end with the back-end system. The next test showed the application with actual back-end data.

Over time, the team improved the product with customer feedback. They included new insights, dropped a few – previously considered “must-have” – features, and integrated a new online service that appeared to be an excellent fit for the solution.

So, what do we observe?

The focus is on creating working software; that’s what we care for!

Documents do no solve user’s problems, working software does.

The focus is the outcomes; the focus is the vision. The team liberates itself of endless discussion regarding functional features. The attention is directed on user needs, and in that problem space, possible solutions (hypothesises) to address those user needs are presented and challenged.

Feature development is prioritised. There’s no all-inclusive upfront analysis, and there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges, or instead, there’s a good design upfront.

We eat the elephant in small chunks, but we prioritize the chunks.

The team organises itself to collaborate. Insights, proposals, experiences, expertise are collected, and in a healthy synergy, the team shares and co-creation happens – with the customer. The customer is central.

Instead of an open-loop system, the project is organised as a closed-loop system: actual feedback of end-users is incorporated iteration-by-iteration to evolve the application and its features. The “apply-inspect-adapt” cycle is a “probe-sense-adapt” approach. The team plans for experimentation, the team is ready to react when new insights arrive. There’s no anxiety about changes.

Lean UX cycle
Lean UX cycle

What about documentation? When required, additional application designs or an overview of architectural components is delivered. Besides that, the product (software) itself is the documentation. Visual elements are documented in the application itself. The developed front-end is the library of reusable components. The web services themselves are established and are self-explanatory in terms of logic.

Modern software development environments and software craftsmanship practices allow this kind of rapid application design, construction, testing and delivery iteratively and incrementally.

More info on Lean UX? Read the book by Jeff Gothelf.

the Sketchnote Handbook by Mike Rohde

Sketchnoting, het visualiseren van informatie – tips & tricks, referenties, workshop

Sketchnoting is het visualiseren van informatie, het maken van aantekeningen, van een verhaal, terwijl men luistert naar een spreker, of terwijl men een tekst leest.

Sketchnoting is een krachtige vorm van expressie, op een heel persoonlijke manier – en laat toe om informatie te verwerken – visueel in plaats van louter tekstueel.

Sketchnoting is niet gelijk aan “tekenen”. De bedoeling is net dat sketchnoting voor iedereen toegankelijk en mogelijk is – zonder dat men een aanleg of opleiding voor tekenen nodig heeft.

Sketchnoting is visualisatie van informatie, het maken van notities. Heel nuttig tijdens vergaderingen, sessies, maar ook fun om te zien of te doen tijdens een event zoals een conferentie.

Visualisatie van informatie en vooruitgang is ook essentieel in teamwork, projecten (“informatie radiators” in agile).

Als je je wat wilt inwerken in sketchnoting, hierbij een paar tips en referenties.

Hieronder ook enkele foto’s van mijn try-out tijdens een sketchnoting workshop.


Zorg dat je een papier en pen bij de hand hebt. Voor een eerste probeersel volstaat dat, maar als je wat vooruit wilt gaan, kan je best een notaboekje en enkele specifieke pennen/stiften aanschaffen.

Sketchnote try-out

Sketchnote try-out

Oefen (offline)

Het is interessant om te sketchen tijdens het luisteren naar een audio/video opname (tip: kies een of andere boeiende TED talk, niet te lang). Probeer de essentie en de verhaallijn te sketchen en niet op te gaan in alle details.

Sketchnote try-out

Sketchnote try-out


Probeer verschillende ‘algemene’ objecten te sketchen zodat je iets van een persoonlijke ‘bibliotheek’ aanlegt van veel gebruikte objecten, iconen, etc. Bijvoorbeeld: standaard vormen, algemene objecten, iconen, pijlen (connectors), scheidingslijnen, letters (verschillende stijlen, verschillende groottes), tekstballonnen, emoties, actoren (mini-mensjes), …

Geavanceerder: voeg schaduw toe aan objecten, meer detail, preciezer en logischer gebruik van kleuren, let op consistentie in schrijfstijl (in eenzelfde sketch).

Oefen (live)

Tijdens een presentatie, sessie, oefen je sketching.

Voorbereiding: maak jezelf vertrouwd met het onderwerp, de titel, de spreker, de locatie, datum/tijd > dit kan je al op voorhand sketchen: het canvas.

  • Aandachtig luisteren
  • Behoud het overzicht
  • Focus op de essentie, focus op ‘quotes’ – maak gebruik van ‘rustpauzes’ of ‘connector’ passages in een voordracht om delen in je sketch te vervolledigen (bv. Wanneer de spreker een fait divers vertelt).

Boek “The Sketchnote Handbook”

De referentie m.b.t. sketchnoting (Mike Rohde).

the Sketchnote Handbook by Mike Rohde

the Sketchnote Handbook by Mike Rohde


  • Focus met je volledig brein (directe informatie verwerking: input van informatie > output in de vorm van een sketch) > stimuleert de concentratie
  • Creatie van een visuele map
  • Zen (voor sommige mensen, bij mij persoonlijk was er een zekere agitatie om het resultaat niet volgens mijn zin was… maar ook je kan je emoties kwijt!)
  • Dynamisch!
  • Leuk!

Andere boeken:

Sketchnote handboeken

Sketchnote handboeken

Enkele resources, online is er nog veel meer te vinden – en vooral deel zelf je sketches online!

Smashing Magazine: How To Get Started With Sketchnotes

UX mastery: Sketchnoting 101: How To Create Awesome Visual Notes

A Showcase of Sketchnotes

Mijn ervaring komt van een workshop sketchnoting met Mara Callaert (@MaraCallaert), de foto’s zijn genomen tijdens deze workshop (bij Namahn, 21/02/2015).