Talk to users. Build what they want. Iterate quickly. 🌱

Why you are not following a process

In all of my interactive agency experience, there is a one constant when working on a project: unpredictability. Websites are complex beasts. It takes a lot of planning and execution to pull off something that looks simple. For the last six-plus years I have been a part of an interactive agency in some capacity. Of course, that experiences includes some transformation in my role. The gambit of experience involves a slow transition from doing work for customers on static HTML websites with simple animations to full-scale enterprise sites for large audiences on multiple devices.

Throughout it all, one of the biggest constants is that every single project is completely different. Even the ones that sounded like they would be exactly like something else you built before, personalities and tastes usually arise that force a new path. For every comprehensive checklist filled with good-natured aspirations for how a website will be built, there are things that are ignored or shortcuts that are taken.

Here's a list of ways to anticipate with these challenges and come out on the other end of your project schedule with a fantastic-looking website. I've seen it work first-hand, it's not a pipe dream.

1. Establish the content on the site and build around that.

The web can be a patchy landscape with a lot of rabbit holes to get caught in. Your audience is there for your content. Not that rad animation you came up with or the gnarly technology stack you are building with. A lot of the time, content isn't ready and we use "lorem ipsum" to fill in the gaps. But content isn't just descriptive, it's also action-based. It's really important to have some version of what the content on the site will look like, even if it is just a rough draft.

2. Create a shared understanding on deliverables and project expectations.

This goes for both design and technical deliverables and expectations. It's important to keep the deliverables lightweight, so there's never weeks where one part of the team is working on a project and a big unveil that falls flat. Sometimes technical aspects of a site are completely missed. Something as simple as browser support, or which web browsers a site will be tested in should really be established up front. Get on the same page and keep sharing throughout.

3. Don't make important decisions without checking with the whole team.

Design by committee is bad. It is absolutely harder to make a smart decision with a lot of people in the room, most of the time. The point is that before a decision is made, talk to who it affects and get their opinion so informed decisions are made. Michael Lopp, author and speaker, gave a great talk titled The Engineer, The Designer and the Dictator that really drives home the importance of having a decision-maker on the team. You do need a dictator who can prioritize goals and set plans in motion. But a good "dictator" in this situation gets feedback from their whole team before choosing direction.

4. Iterate and deploy as often as possible.

Don't let team members work in a silo, even if they are senior-level or you trust them. A talented worker can still make costly mistakes if they are not kept in the loop and collaborating with others. It's important to have peer code reviews and sanity checks as often as it makes sense. It's the same as asking this question: Why would you walk ten miles, when there's a bike sitting right there? The workhorse, go-at-it-alone mentality is the 10-mile walk. The continuous checkpoints and collaboration are the bike. When you can chunk out work and test as you go, you have working examples and trackable changes that will help you de-bug or improve on a feature. It's important to know what problem you are fixing:

This is what I've found from my experience. If having a checklist that you follow religiously works for you, I'm not saying that is wrong. But if you are doing all of the things above, you are going to build something everyone is happy with.

Want to stay in the loop on what's happening at Sign up for the mailing list.

* indicates required