The Liberators
Published in

The Liberators

How we built incrementally

When the idea emerged to build a website for The Liberators, we immediately decided that we wanted to do it in a truly iterative fashion. No detailed upfront designs, no traditional separation between design and development, but a cross-functional team that was capable of delivering incremental versions of the website on a daily basis throughout a 5-day build week.

Our team

The incremental nature of the work meant that we didn’t know exactly what kind of work would be coming our way. Working together with our strategic partner Fonkel, we decided on a fluid team composition consisting of a stable core of three developers (Ewout, Daniel & Christiaan), a designer (Wim), an animator (Laurens), a Scrum Master (Nicolien) and of course our Product Owner (Barry). We could tap into the skills of a professional writer (Lianne), a photographer (Lisanne) and an additional developer (Maarten) as needed.

Our core team — Barry and myself included — was present for the entire five days. With the exception of some other work, we all focused on being present throughout the week and work on the site with focus. In addition to having a core team, we also got to transform one of Fonkel’s offices into a dedicated ‘team room’.

Incremental design

One of the challenges when building a website is how to design incrementally. It is no secret that many designers balk at the idea of incremental design, believing that “you have to get it right before you show anything”. And despite our penchant for incremental work, there is certainly a kernel of truth to this. You need to have at least a sense of direction. So we agreed to spend a limited amount of time before our build week to craft a rough black-and-white wireframe of what our website was probably going to look like. We also involved the developers to make sure that the approach was also technically feasible.

The initial (rough) wireframe for the website, designed one week before starting with development

Starting on day one of the build week, our designer started fleshing out the wireframe as needed with colors, fonts and content. Rather than designing a pixel-perfect representation of the entire site or individual pages, he focused on items that were either under development or would be picked up for implementation soon. Usually, developers would simply ask for design guidance when needed. In other cases, the need for design was coined during one of the Daily Scrums. In all design-work, the Product Owner was involved in the first check of new designs.

Most of the design work was done in a wire-framing app called Sketch which the designer then shared through InVision for feedback. The designs made in Sketch tended to be rough and basic, offering developers a general sense of the structure of the page (or a chunk of a page), the use of colors and elements and how people could interact.

A rough design made in InVision, ready for the developers to implement.

When the grid-based structure had been implemented by the developers, design-work shifted to fleshing out individual tiles of the grid.

Rather than designing entire pages, individual components where fleshed out as needed in a style guide

An interesting observation is that our designer was expecting to be done with design-work halfway the buildweek. But as new insights emerged, additional design was needed continuously:

  • On day three we decided to limit the number of customers we work with to just four per page (instead of 8 or more). Based on the work done up to that point, that felt like a better fit in the grid-like structure we had come up with;
  • On day four we decided to break up the ‘About’-page into a page that simply listed the platforms where people can follow us (‘Follow us’) and a page where people can get in touch (‘Liberate me’). This felt more logical from the perspective of what visitors may be looking for;
  • On day four we discovered that we hadn’t given much thought to what the menu would look like on mobile devices. We spent time on this, also asking for feedback on LinkedIn using a video to explain the issue;
  • On days three and four, the designer spend a significant amount of time to review the work that had been done up to that point, identifying minor oversights in styling or presentation issues on certain devices that had been missed in earlier testing;
We used an impromptu end-of-day review to review what everyone had been working on. Here, the designer shows new designs for elements to be implemented later.

Another thing we noticed is that it was consistently harder for the Product Owner to provide useful feedback to designs than to fleshed-out features in the actual website. Without being able to click through features, see how they fit in the bigger picture, the Product Owner often had to ask for changes in how features turned out. This feedback then had to go back to the designer, then to the developers and finally back to a new version. This is a great example of how a “Done”-increment (=working, deployed functionality) provides a more better foundation for empiricism than simply a design of what it should look like when done. We should note here that for the developers it felt more efficient to have the design signed-off and completed by the designer, even though the Product Owner felt differently about this with regards to the value generated by such a multi-stage process. This shows the challenges that Development Teams face when working collaboratively to iterate faster.

Incremental video

Our website features several videos, like our ‘Under Construction’-video. Having only recently started with YouTube, we felt that we could professionalize this part of our content. So we added a professional animator, Laurens Verwijs, to the team to help achieve this. His work primarily consisted of creating an animated introduction (a so-called leader) to our videos. But he also spent time adding this leader to existing material on YouTube.

As with design, a challenge is how to do animation incrementally. Laurens took this on by ending day one with a rough version of a potential leader and added it to various existing videos (together with a custom thumbnail). Day four was spent creating a more detailed animation and sound was added on day five.

Incremental development

One of the first questions that emerged when building our new website was whether or not we needed some sort of content management system (CMS). We decided against this. Not only would the implementation of a CMS greatly increase the complexity, it would also make the site heavier. Instead, we opted for a lightweight static website based on Jekyll (a template-based generator). One of the benefits of Jekyll is that it allows you to store structured data in separate datafiles that are then merged into the HTML upon a ‘build’. More importantly, we wanted to leverage the dynamic platforms we already have — like Medium, Twitter, YouTube and LinkedIn — instead of adding another one (our CMS) that we would have to maintain. We also felt that it was unlikely that the content on the site was going to change very often, removing a clear need for an easy way to update content. Should a strong need arise in the future, we can either implement a CMS at that point or dynamically generate the data-files that Jekyll uses from the various platforms that we use. For the near future, we can make necessary changes to the datafiles manually and re-deploy the site.

Our Product Backlog consisted of all the work needed for our website that we knew of at the time. It changed continuously.

As you can see from the picture, the Product Backlog included functional items as well as technical tasks (e.g. ‘Minify JS’), content that needed to be generated (videos, blogs) as well as bugs that we discovered during development. Although we used a user story-like pattern for some of items, we didn’t for many others. For example, ‘Platforms in two columns’ captures the outcome of a conversation between developers and the Product Owner and was enough to act as a reminder of that conversation. We did try to keep most of the items functional, making it easier for the Product Owner and stakeholders to understand what was on the board:

  • Visitors can reach out with a potential lead through an in-site form;
  • Visitors can reach out with a potential lead by clicking our email address (no form);
  • Visitors can view participant satisfaction with our classes;
  • Visitors can sign-up for the newsletter;
  • Visitors can see an average satisfaction rating with our classes based on actual data from participants;

Having split the website into small, vertical slices allowed us to release to production very often. Starting from a bare-bones-version of our website, it allowed us to rapidly iterate (between 5 and 8 times a day). This animation shows the work done up to the end of day 4.

This animation shows how our site gradually grew over a period of four days.

We started every day by identifying the goal for that day and then proceeded to select the work we wanted to do to achieve that goal. For day 1 our goal was to ‘have a website with logo and slogan online’, while the goal for day 2 was to ‘demonstrates our comic book concept’. Throughout the day, we synced our work periodically as a team and made decisions about work to add or to remove.

A picture of our Daily Scrum. Having a clear goal for every day helped us keep the focus on what was important. On several occasions, the developers reminded the Product Owner to keep work limited to what mattered to the goal.

Incremental value

The purpose of our new website was to act as a gateway to the many channels we use to distribute content. We invested 25.000 euros (~28.500 US dollars) in the creation of this website and associated content. Obviously, we did not want this investment to go to waste as it represented a significant chunk of our total revenue.

Starting from day one, we plotted the money we had spent up to that point on a burn-up chart that was visible to all. Both at the end and the start of a day we inspected the chart together and made decisions about what to add or leave out.

We’ve blurred the amount of money spent to respect the hour rates of our strategic partner, Fonkel

In terms of value delivered, it is still too early to tell if the website is delivering on its purpose. But the metrics we’re tracking are promising. We’re seeing a huge increase in traffic (excluding our own traffic), we’re seeing many new followers on Medium and we’re seeing an increase in the number of people that are following us on YouTube. Ultimately, our website is valuable to us if it makes it easier for people to connect with us, to be inspired with new ideas and when it shows them the value that we can offer them in their professional journeys.

Some of the metrics we track to measure the impact of our site. All show increased traffic, hits


Building our website incrementally was a blast. Not just for us, as customers, but also for the team building the website with us. Everyone felt engaged and motivated to contribute, while keeping a clear eye on the budget and the purpose of the website.

We started development a detailed scope. Although we did have a Product Backlog to start with, it wasn’t fixed by any means. Instead, we had a fixed amount of money we wanted to invest and a clear purpose we wanted to achieve. With those in mind, the scope was fluid. Because we took care to order the work-to-be-done according to the purpose we wanted to achieve, we always worked on what was valuable for achieving that purpose. By releasing increments every day, we were able to gather feedback from visitors, friends and colleagues and adjust accordingly. And it was mightily motivating for everyone in the team to see things come together over a week’s time.

So now what? Although we are happy with the site as it is now, we have many additional ideas. For one, we want to actually share with you a number of ‘comics’ about themes we care about it. But that is for another Sprint :)

We hope you enjoyed reading about, and following, our progress. Hopefully we inspired you to try something similar with whatever you are developing. Check out our videos on YouTube to see a bit more or read our other posts about the website on Medium. And feel free to check out our website:

Interested in learning many different Liberating Structures in an intense 2-day workshop? Check out our agenda for upcoming Immersion Workshops. If you’re aiming to join, book early — they are exceptionally popular. And join the Dutch User Group to learn more about Liberating Structures.

You can already support us with $1/month. Find out more on




The Liberators: Unleash The Superpowers Of Your Team

Recommended from Medium

June 2020: UXperts round-up

How To Improve Registration & Sign In Process

Blog Post 1: The Museum of Awe

Idea Generation Part 2

Swag Secrets: Stickers

How to Create a Logo That Adds Value to Your Brand

Armchair Academy: RSRCH 101 UX Research

Venmo Case Study

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christiaan Verwijs

Christiaan Verwijs

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.

More from Medium

Growing from one Scrum Team to three Scrum Teams

Agility And Business Agility Are The Same

Retrospective meeting on a remote setting

Why Governments need to be Agile in 2022