We always strive to innovate the web design industry. Apart from testing new shiny things, we cherish questioning our habits and reviewing our processes for the sake of improvement. Having delivered hundreds of projects in the past few years, it has given us many opportunities to learn from mistakes and provide a more satisfying experience to our clients. This article takes you through one of those conclusions, which changed everything for the better.
The context in this article is for web design and development, but the same observations and takeaways can be applied to any business size and type in any industry.
Our agile web design process evolves rapidly, but we always keep this article up-to-date. You can check the latest update status at the end of the article.
Our first cue to dig deeper into the possible shift in the approach was the timescale needed to build a website. On numerous occasions, we heard from leads, clients, and even other agencies that the turnaround to build a website is always too long for them.
Even though websites aren’t that complex at first glance, there is a lot that goes behind the scenes before you can publish them. We don’t mean it as an excuse, but as a fact. On top of that, we are a very meticulous bunch.
Regardless of the inconvenience and given the promised quality, businesses were happy to work with us. But the question didn’t die down and kept bouncing around the office.
Eventually, we have arrived at the conclusions shared in this article. We hope it saves you endless hours of research and pushes you in the right direction. Our goal is to change the Web for the better so that everyone can enjoy it with as little frustration as possible. We firmly believe our agile web design process is a step towards that, so let’s dive into why and how we’ve changed as an agency.
There are two approaches worth mentioning here. One of those is called the waterfall. It’s been introduced by Dr Winston W. Royce in a paper published in 1970. You can tell it has been around for a while, and for a good reason.
A waterfall development process is a linear approach to a project where tasks get done one after another. They are subsequential and the user can’t move on to the next one without ticking off the preceding step.
An example project in the waterfall model may look like this:
We have great things to say about it, but let’s start from the very beginning.
First of all, waterfall expects you to plan the whole project upfront. This gives you an idea of the needed resources and the cost. It defines clear milestones for everyone involved and provides a chance to question deliverables before committing.
Secondly, the client knows exactly what they get from the get-go. They can start planning their marketing strategies around the launch date and prepare their business for the upgrade. Additionally, the waterfall works brilliantly with a fixed budget.
Unfortunately, there is another side to the coin.
As we’ve mentioned, in the waterfall method you need to do tasks one by one, so it’s extremely easy to face delays, which cause the ripple effect down the line. The system is so fragile it’s enough that a team member gets stuck with their responsibility and before you know, the deadline is postponed again and again.
And it’s reasonable to assume that you will get stuck. It only takes a third party releasing an update to an integration that forces you to change the way you do things. Sometimes it will be totally out of your control. You can plan for that, but you’ll never know the exact implications.
Another dimension worth mentioning is scope creep, which is an unexpected turn of events, which you couldn’t have possibly predicted (hence unexpected).
Since waterfall-driven website builds take at least a few months from start to finish, it’s highly likely the client will want something added halfway through the job. It renders plenty of issues because you have already agreed on the price, created a roadmap, and organised your team resources. Yet, you can’t blame the client because a company is a living entity that evolves, grows, and changes all the time.
To cut the story short, we have decided to switch away from this model, because it imposed too many limitations and the benefits didn’t outweigh them.
As the search for a better way to deliver websites continued, we turned our attention to the agile model. We knew about it from our peers in software development, so we’ve decided to investigate how we can translate it to web design.
Popularised by the launch of the Agile Manifesto in 2001, the agile software development method emphasises evolving solutions through collaboration and self-organising cross-functional teams. In plain English, it comes down to the ability to create and respond to change.
It keeps impressing and drawing people in because it’s simple to the bone yet ludicrously effective. In short, it breaks projects down into a collection of smaller jobs which together make it complete. Yet these portions bring business value on their own too. Those jobs are then shredded further into actionable tasks, which help to estimate the timescale and the cost involved in the project.
With the detailed breakdown at hand, so-called sprints are planned which deliver those tasks within a certain time frame. When a sprint ends, the client gets a finished part of the product, which is independent and functional.
Sprint is an agreed period of time, usually between 2 and 4 weeks, in which a team delivers a set amount of work.
Prioritisation here is the key to success. Once there is an overview of the project, one can shuffle the list of requirements so that the vital parts get delivered first, and thus the product goes live sooner rather than later.
This approach remains flexible and open to scope changes throughout, too. The client can add and subtract requirements at any point in time because the project planning operates on the fine detail level. Furthermore, the client controls the spend because they pay upfront for each sprint. In case they want to put the project on hold, they certainly can.
At this stage, we were extremely excited. We knew we were onto something, but we had our objections. We couldn’t fully embrace agile just yet.
One of the issues that were rightfully pointed out by our team was the difference between software development and website development, and the resources both use. Agile was invented for bigger teams that handle projects that span across many months and employ several developers working full-time around the clock in parallel. Websites aren’t that complicated, and in our case, one developer per website build has always been enough.
Next on the list was the “all-in or nothing” bit. In the agile world, it is black and white. No mid-tones. Whoever is part of an agile project needs to follow the same principles or else the project fails.
Now, how do you write the copy for a website in the agile model?
What about the design?
Can it be part of something that was originally built to produce software?
It’s getting crazy here.
The final thorn in the neck is the difficulty of pricing the project upfront. You can’t commit to a fixed price, because agile goes against the concept of being tied down. Yet many clients will want to know the cost before they jump the ship.
Eventually, we came to the conclusion that might’ve been circling your mind while reading the previous chapter. To make agile work for our agency, we had to find a way to run design and development in parallel. It wasn’t long before we’ve found the solution. Or, to be accurate, the inspiration for the solution. It was the Design Sprint process, originally invented by Google Ventures and used to build software and brands from the likes of Gmail, Red Bull, and more.
In short, our interpretation – a Web Design Sprint – is a way to build a user-tested prototype of a website in a week. Yes, you read that right. In just a single week. We always recommend running at least two iterations to iron out issues and action the feedback from user tests, but in extreme scenarios, it could take a single week.
We achieve that by running three workshops with the client’s team, which then help us build a prototype in just one day. On the final day, we test it with the target audience, and that’s a wrap. This article is not the place to go into nitty-gritty of the process, but if you’d like to learn more, here’s a good summary of our agile web design process on YouTube.
Here are some high-level conclusions.
When you contact our company with a website project, we will suggest a meeting to go over our process. Assuming you are happy with the presented ideology, we will book in a couple of workshop sessions. It means we spend a few hours brainstorming and nailing down the requirements. Post-it notes everywhere. Sketches. Jugs of coffee.
The reason behind it is to get everyone to sing off the same page. We need the workshops to have merit to provide a rough cost and the estimated time of delivery based on the agreed points.
And the outcome of the workshops can be really surprising. It’s possible that we’ll come to a conclusion that your website isn’t the biggest issue with your digital marketing – imagine how much money that could save you! You can also put a stop to the project at any time. The goal of each weekly iteration is to deliver real value to your business. If you decide to go for a different contractor or to delay the project to raise additional funds – it’s all entirely possible.
If you decide to stick around, by the end of the workshops you would have learned a lot about your concept and the way forward. You will have a website prototype tested with real users, validating our ideas. And by “our”, we mean the team which consists of us and experts from your company. You have full control throughout the project and your insights contribute to the outcome.
At the end of the workshops and user tests, we will have a list of potential improvements and required features to achieve your goals. By that time we’ve looked into your business goals and we can see how to align the website to support them.
In a scenario where our workshop ideas were validated by the target audience and you wish to go ahead on that basis, we will estimate each deliverable to get the sum of story points needed to complete the project.
In agile, the story point is a measure of complexity. This is much different from the usual estimations based on hours. But it’s also much more intuitive than it seems. In other software projects, it’s risky to estimate a velocity based on the previous work done for other clients. That’s because there are fundamental differences between them. But if you only build a specific type of software and stay within that niche, you can afford to do that kind of estimation.
It’s not an accident that websites fit in that category. Once the tasks are estimated, we can give you a rough idea of how long it will take to complete based on other, similar projects (and we have lots of them, which reduces the risk even further). As always in agile, the scope is infinite – it might be that we finish the work in week two and you say “wow, that’s ready to launch!”
It also might take five weeks instead of the planned three because you, or our team, had lovely ideas that we’ve agreed to complete before launch. The flexibility helps maximise the return on investment.
As for the backstage, we use Kanban as our task management framework. We also use Scrum sprints, together with their typical ceremonies. Kanban isn’t sequential and it fits well in a website project, which is ever ongoing and changing. It’s also amazing for our “business as usual” tasks, which we will describe soon.
Thanks to that framework, people responsible for content writing, design, and development can be part of the agile environment. If we look at the website as a series of singular components, we can predict what will be needed in subsequent sprints and delegate tasks to people accordingly.
Each task has a clear Definition of Done (DoD), which sets expectations for everyone – the agency, and the client. We split it further into Design Spec, Dev Spec, and Content Spec. With that separation in place, developers, designers, writers, and testers know exactly what’s required to mark the task as done, and the client knows exactly what they’ll get. Win-win.
Even our version of the agile model struggled to deal with unexpected and urgent requests. We all get those regularly. We take pride in building lasting relationships with our clients, some of which have been with us for over 5 years and have built multiple websites. So the last question needing an answer was: how do we handle ad-hoc jobs?
The answer was, as always, in the prioritisation and organisation of the workload. Back in the day, we would drop everything when an urgent email arrived in our inbox. It caused mayhem in other projects’ schedules and kicked the people out of their routines. Obviously, the urgent ticket was resolved almost immediately, but at what cost? At the cost of padding and longer deadlines for clients, which we’ve discussed at the beginning.
Since we were overhauling how we dealt with projects, we decided to fight this, too. We came up with a template for the daily routine, which is solid grounds for many. Of course, it is flexible and is being adjusted as we go.
We begin at 9 AM with a few minutes long catch-up about the current workload. This is our equivalent of Daily Scrum meetings. During the meeting, we look retrospectively into the jobs and set the course of action for the rest of that day.
We jump straight into the current projects. We guarantee to deliver 30 hours of work during an agile sprint, which leaves us with a couple of hours each day to tackle the ad-hoc requests. Being able to do it on a retainer basis gives us a very clear expectation of the expected workload.
3 PM is our cutoff time for next-day requests. It’s subject to availability, but with over a year since we’ve implemented the process, it has worked flawlessly so far.
To wrap it up, so you don’t leave without food for thought. It’s been one of the biggest tasks to revamp our internal processes so that the experience our clients get is as excellent as it can be.
I think that agile is just a concept that is great at the core but needs adjusting before it can be used in production. Many web design and marketing agencies firmly stand by the waterfall model and one can’t blame them. It’s very logical and methodical. As long as it makes them efficient and timely, why change. In our opinion, websites operate in a rapid environment, which forces adaptation at every step. To take care of them in the logical and methodical approach such as the waterfall model is a shot in the foot.
Our agile way isn’t the end of the road. It’s not perfect. It’s not meant to be.
It’s something that we feel is the most productive at the moment, but we will be on the lookout for things that can be improved.
Our ultimate goal is to innovate and to make the Web better. We’re getting there with the help of peers, and with the trust of our clients. If you think you can help us as well, don’t hesitate to get in touch with us on social media, or by dropping us a line at email@example.com.
Do you have any ideas that would help make web design better for everyone? Let us know.
Originally published Dec 12, 2019 9:37:00 AM, updated September 24 2021.