How we built TheLiberators.com 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.
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’.
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.
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.
When the grid-based structure had been implemented by the developers, design-work shifted to fleshing out individual tiles of the grid.
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;
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.
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.
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.
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.
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.
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.
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.
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: https://theliberators.com
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.