Custom WordPress web development is one of the things we do here at Kick Point.
It’s fun, challenging, and sometimes makes you want to pull your hair out when you’re doing QA for the sixth day in a row and can no longer remember why you decided to try a new category filtering system on this project, with this budget, with this timeline, in this lunar cycle. With Jupiter in the seventh house? What were we thinking?!
You know how it goes, everything’s simple in the beginning when we dream big with our client about the best solution for their site. But a week from launch, with the bug fixes piling up and the client finding issues every other minute on the live site, we’re ready to change professions to something where we never have to touch a computer again (do those even truly exist anymore?).
If you work in an agency, this might sound familiar. Scarily familiar, maybe?
We (and our clients!) ended a lot of our web projects in the same way: tired. A more complex web design project might end up taking eight months or more. That’s a long time to keep momentum up, spirits high, and scope in check.
After some soul searching, much brainstorming, and from some help from our friends at the digital project management consultancy, Louder Than Ten, we realized that we were approaching projects the wrong way. And chances are, you might be too.
What is Waterfall web design and development?
Waterfall is a project management methodology where project activities happen in discrete, linear steps. One step is done, reviewed, then the next step begins. In web design and development, it describes a process of phases that might go something like this:
- Determining the direction of the site through a discovery/strategy phase. This involves uncovering the problem that needs to be solved by a new website, researching the audience, auditing existing content, doing keyword research, and more.
- Creating a sitemap, content structure, and functionality list. This is where the findings of discovery turn into a concrete plan for what content will be on each page of the site, how those pages interconnect, and what special features the site needs.
- Turning that plan into wireframes. Wireframes are black and white “blueprints” of the visual layout of the site to confirm hierarchy. Often these are built in a tool like Invision, which allows for low-fi prototyping.
- Turning the wireframes into high-fidelity design mockups. This is where colours are applied and everything looks like how the site really will once it’s finished.
- Passing those mockups off to a developer. They then go away and turn them into a website (MAGICALLY, in the opinion of the non-devs on our team), connected to a WordPress content management system (CMS).
- Doing quality assurance on the site after it’s been developed, uncovering bugs and then fixing them.
- Training the client on using the CMS and handing it off to them to do content entry.
- Launching the site once content entry and bug fixes are complete.
Waterfall is how Kick Point used to and — we’d hazard a guess — many agencies still run their web design projects. (For clarification, we’re talking websites here, not apps/software.)
There are reasons why Waterfall has been the predominant form:
- It’s a straightforward and easy process to explain to clients
- There are less meetings and feedback loops required, so it feels like it’s saving time
- Scheduling is straightforward, because a developer doesn’t need to touch the project until the designs are all finished and approved
- Other methodologies require a project manager or team lead who can be very involved in running the project
- It’s how print projects usually work. Make your layout, send it off to be created. It feels comfortable because it’s how things have “always been done.”
The biggest issues with Waterfall web design & development
While running our projects in Waterfall didn’t always go poorly for us, we found we were consistently hitting the same issues over and over.
If you work at an agency, do any of these sound familiar?
If a client isn’t happy with the design direction, all page designs need to be changed
If you present a full design, with all of the pages in a certain aesthetic direction, a client might come back with feedback that affects every single page. That means your designer is going to have to redo work that’s already done… a good recipe for going over budget and sailing past your deadlines.
The budget gets gobbled up by earlier phases, and there’s no time or leeway to change the plan
When you’re working in Waterfall, every phase needs to be completed before you move on to the next. That means that if you go over budget in one phase, you’ll need to pare back in the next phase. But if all of your designs have been approved, you can’t really ask the client at that point if you can go back to the drawing board and cut some features. Well, you can, but it’s a tough conversation that often doesn’t go well.
Developers aren’t involved in the project until it’s too late for their input
In the traditional Waterfall approach, a developer might be involved in quoting, or a designer might ask their opinion when they’re designing the UI for a feature. Or they might quickly review the designs before they go out to a client. But on the whole, they aren’t really brought into the fold until the site designs are done and they’re supposed to start developing the site.
The issue with that? Only they really know how complex a template will be to code. Only they know that that slick hover state we imagined will actually take twelve hours to get right, not two. These are the types of issues that only really get caught when a developer is engaged with a project and has the time to start planning their build early.
Problems don’t always present themselves until they’re coded
That banner looks awesome in the mockup, but now that we see it resized on an iPhone, it looks totally off. Crap. Now what?
Sure, we might have been able to anticipate this issue, but some things aren’t obvious until they’re coded. When a whole site is coded at once, you don’t catch these issues until the end of the project, when you’re running low or out of budget, can’t go back to the client with a change, and just need to get the damn thing finished.
Clients might not recognize an issue until they see it on a live site
If we can’t anticipate every potential issue with a design, how can we expect our clients to be able to? We have clients sign off on a full site design with the hope that they really understand how things will work when that flat mockup becomes a functioning website. But unless they’re also web designers, that’s a tall order. When we don’t let the client see and use the site until the day before we’re aiming to launch, it’s no wonder we’re left with a huge list of requests from the client since “this doesn’t work how I thought it would.”
We lose momentum and the client isn’t engaged
Projects tend to drag for lots of reasons. Sometimes you haven’t prepared a client for how much time they’ll need to spend gathering feedback, writing content, or arranging interviews with their stakeholders. Or sometimes things just aren’t coming together smoothly with the site plan or design. It happens. But by the time we get into development and then pre-launch QA, we’ve lost all the excitement that our project started with.
In the beginning, there are concrete things to see and fun decisions to make. During development, there’s a whole lot of waiting and slogging through for both our team and the client’s.
The client just has to wait, anxiously hoping that we’ve been able to translate their needs into a useful product and that we’re going to meet the timeline their boss is demanding. It’s tough and tiring.
QA is long and exhausting
If you’ve ever done QA on a website, you know it takes a lot of time. There are a few people who genuinely enjoy this work, but it’s truthfully not a task that most of us want to do for days on end. It’s a lot of clicking, screenshotting, and writing, “this is what should have happened but this is what happened instead.” When you have an entire site to QA at once, it can feel like an unclimbable mountain.
So yeah, Waterfall sucks. But what do we do instead?
We had heard a lot about Agile project management, but had our doubts. At a very high level, Agile is a framework for managing projects that involves regular iterative phases (called “sprints”) and teams from different disciplines working closely together. When it comes to web development, the idea is to build prototypes of features early so they can be tested with real users.
Agile (and its specific methodologies, Kanban/Scrum), is often used for software development, and it’s a complex framework that we truthfully haven’t fully gotten into.
But that’s okay, because as website designers and developers who aren’t building apps, we don’t really need to be fully agile. Instead, we can be Agile-ish.
How we experimented with some Agile principles in our web design and development process
We started by thinking through our main process pain points:
- Dev wasn’t involved until it was too late
- Client feedback caused design work to be redone
- Issues were introduced in dev that then spread out to all pages
- The end of the project is tiring and frustrating for us and our clients
Then, we thought about how we could fix those problems.
Get dev involved as early as possible, without bogging them down too much in the discovery process or bloating our budgets
We didn’t want our devs sitting in every client meeting — that would be a waste of time and budget. Instead, we started to think about when their feedback and input would be the most helpful, and how early we could get them started building the site we were planning.
We realized that we could start planning the admin of the website (how the client would be able to update their content, what those content fields would need to be, how many templates there would be, what types of components might be on the site) way earlier than we had been. By the time we had an approved content plan (which we build out in Gather Content), we could really start mapping out these fields.
That turned into a spreadsheet that the project strategist and developer would work on together.
After wireframes were completed and approved by the client, the strategist and developer could run through the spreadsheet and make any adjustments that came from client feedback or the designer’s ideas. Then, the developer could get started on setting up the admin of the website: setting up the server, building the page templates, setting up Advanced Custom Fields.
This allowed that foundational work to be finished early and reviewed, so we would be ahead of the game when answering questions like, “how is the client supposed to edit this content? Which parts? To what level?”
In Waterfall, those questions would be answered as we were trying to get front-end development done, and there often just wasn’t time to get it right.
Break up design into rounds
This was such a simple solution it feels silly to even present it here. Don’t design all at once. Once we realized we could present design in rounds, we could then start developing in rounds, and QAing in rounds. We hesitated calling them “sprints” for a long time because it felt too official and Scrum-my but that’s really what they are.
Our clients now see a homepage design first, which presents the overall aesthetic of the design, the navigation, header and footer. It’s a good place to start because often changes here would end up affecting the rest of the pages.
Then, we present two or three more pages in another round, then three or four more in a final round. Each round, we tend to get less feedback on the aesthetics, because we’ve already worked through any issues that the client had earlier on.
Use sprints for dev, too!
In Waterfall, a simple bug that could be fixed easily if it was found early tends to proliferate throughout the entire site. An easy fix cascades into a big, time-intensive one to tackle at the end of a project.
Breaking up design into rounds gave us the freedom to explore developing in sprints. Instead of a traditional sprint where you might only work on one feature to completion, we instead decided to do this by pages.
Our developers now take a finished homepage design and develop it completely. It’s then passed to our QA team for review, and then the client can review it. Since the backend is done and set up, we can actually get the client in there so they can practice editing and adding content.
Working like this helps us catch issues super early in the process before they get duplicated across all of the templates on the site.
It also allows the client to provide their feedback and thoughts early, at a point where we can make real decisions about how to proceed. That might mean increasing scope, or reducing the complexity of another page.
Keep momentum going with regular “wins”
One of the major problems with Waterfall is that development and QA feels like spending a million dollars to ship your child off to a training academy, spending three years waiting and expecting them to become a world-class athlete, and then ending up with a bronze medal win. They’re still an Olympian, sure, but they still have work to do and the whole thing feels like a bit of a letdown. You weren’t there to see how hard they worked and the amazing strides they made along the way, so the reveal is kinda anticlimactic.
For both us and our client, there were very few visible wins during the development process before we changed our process. We tried to high five our developers when they finished a milestone on their end, but often no one else could see it because they were developing locally.
By working in sprints, we regularly have real, live, finished pages to review!
This keeps the momentum going because we’re seeing the fruits of our labour come to life quickly, we’re problem solving together, we’re not panicking about budget or timeline, and the client can actually see that we’re doing what we’ve said we’re doing. And there’s a lot of trust that comes from that kind of visibility.
Final thoughts
We’re super happy with how our new agile-ish process is going. We’re still learning, adjusting, and getting better. We’re figuring out how to manage scope and budgets more effectively (more on that another day).
When we asked our team how they felt about our new process, a metaphor quickly materialized because we’ve got a prolific knitter on our team… and we love metaphors.
Developing a website is like knitting a sweater.
In Waterfall, a developer has been given a pattern for a sweater and told, “Knit this as fast as you can with whatever bits of yarn you have hanging around ‘cause we don’t have much time or money left. But it needs to look exactly like this pattern okay?”
So the developer rushes through the sweater, not realizing that there are a bunch of holes and stitching errors in it the entire time. Then she hands it off to be reviewed in QA, and everyone says, “Um, hi? Look at this mess! This is the wrong colour, and you did a cable knit here when I meant it should be a lattice.” And the developer then has to go back and painstakingly pick through her stitches to fix them, but they can never be as perfect as they could have been if they were done right from the beginning. Oh, and it takes longer than it would have taken if it hadn’t been rushed.
In our new Agile-ish approach, the developer helps build the pattern, understanding how the sweater should look and feel. She starts by knitting a small test swatch and asks everyone, “Is this what we were all imagining?” If she needs to make changes, it’s easy. She’s got the time and budget to use the right materials and isn’t stressed, so her knitting comes out much nicer. There are still mistakes, but we catch them before they take over the whole sweater.
What a nice little analogy hey? Now go knit a sweater… just don’t do it all at once.