The internet is a massive and constantly evolving system. Web users are complex beings with unpredictable behavior patterns, desires, and impulses. The act of creation is messy and nonlinear. Organizational goals and priorities are never unanimous and often competing.
For all these reasons, and more, building and launching a new website is hard. You’re manifesting a new entity to fit seamlessly into an existing ecosystem. Your creation needs to be easily found and quickly brought to life. It needs to answer the many questions of your different visitors. It needs to satisfy the curiosity and whims of both known and unknown audiences. It needs to be captivating as it tells your story and structurally sound as it supports your users’ needs.
It needs to make your bosses happy with their favorite fonts and colors. It needs to make your customers happy by giving them what they want, when they want it. It needs to make your shareholders happy by lining their pockets.
That’s a lot of pressure.
Depending on your organizational structure and your place in it, web projects can be a real drag. But they don’t need to be.
Here are some things we can do to take the suck out of working on the web.
Put together the right team
For a web project to be successful, and fun, the project team needs to have people who...you know...understand the web. That should go without saying. But I quickly learned that this assumption will make you a butt.
I’ve worked on projects with agencies that, theoretically, should understand how web projects go. Organizations that call themselves digital and should probably have seasoned web experts. And then the project started and I found myself on a digital island (with the exception of developers).
What happened?
A lot of the big-time agencies have been around for awhile. They have years of success and big reputations, which they built in the print world. When you’re successful at something for a long time and you’ve built a name on that success, it can be hard to see the world changing around you. They realized too late that the internet was the future and they needed to catch up. So they spun up “digital” branches of their business, but they failed to understand that digital work and print work are different. So they used the same print creatives, project managers, and processes they always used.
Now they have print designers creating “web” templates in Photoshop—without understanding browser limitations, accessibility, or usability—and handing them off to developers to code. They have print writers without a fundamental understanding of SEO, web best practices, or content strategy. They have project managers printing webpages and marking them up with red pens.
And on the other side of the table they have exasperated developers who don’t know where to start with the feedback.
If you’re building websites you need to hire web people. A print writer or print designer can also be a web writer or web designer, and vice versa, but it’s not a guarantee. You need people who understand the web to produce and manage your creative.
So who do you need on an ideal web team? Depending on the size and scope of the project, you need at least the following (disclaimer: this reflect a minimum of skillsets, and assumes that several team members will be able to wear multiple hats):
Project Manager. This is the person who will establish and communicate priorities, goals, milestones, etc. between leadership and the team. They’ll mediate conflicts and fight scope creep. They’ll track progress and workflow. They’ll set timelines—including plans for QA. They’ll facilitate communication between team members. This person needs to have experience managing web projects. If they don’t, then you need 2 project managers. And the other one needs to have experience with web projects. Think of it as an apprenticeship for your non-web project manager. Someone who has never managed a web project simply won’t understand the level of complexity, the importance of QA and bug tracking, the amount of time things take, or the best way to work with different team members.
Strategist. This person will help the project manager establish the goals of a site and develop strategies to achieve those goals. Ideally, your strategist will be a Renaissance person. They’ll need to understand at least a baseline of marketing, IA, UX, Social Media, SEO and SEM, asset acquisition (for photography/video), and business goals. The strategist needs the answer one question for every element of the site: “Why are we doing this?”
Developer. This is obvious. To have a website, you need someone who can build it. But don’t treat your developer like a code monkey. I’ve worked with developers who are the most creative problem solvers on the team. They should be involved in strategy and timeline conversations early and often. Their vast knowledge of the web can be an invaluable resource when you’re considering options and developing plans.
Designer. A designer should play 2 crucial roles on a web project:
- Make the site beautiful
- Make the site useful
That second one is key. Designers have an eye and talent for making beautiful things. That’s why they’re designers. But I’ve seen too many companies with designers who design in Photoshop, then have the developers replicate their work on the web. How is this still happening? How are we using people to design for the web when they don’t design in the medium? Let’s say I call myself a chef, but I don’t actually know how to cook. So I write down the ingredients in a dish, and somebody else cooks it. Gordon Ramsey would chew my ass.
Now, before everybody gets their hackles up, I’m not saying that designers who use Photoshop and Illustrator aren’t valuable to an organization. I’m just saying they’re not web designers.
I understand that design and front-end development aren’t the same skillsets. But to be a web designer, I think you need to have both. I know people can do both are out there. I’ve worked with some. And I can’t tell you how valuable it is to have a designer who understands the capabilities and limitations of the web and accounts for them during the design process.
I suspect we’ll start seeing more and more people who are trained in both areas.
Writer. I’m a writer by trade, so I apologize ahead of time if this is a pity party. But us poor writers. Marginalized, ostracized, ignored. We’re the last thing considered on most web projects. Leadership looks at the colors, the photos, the flashy functionality, and they ignore the words. Industry kudos is given to beautiful designs and new features. My mom still doesn’t understand that I’m a writer, not a developer or a designer.
And then a user visits the site. And all they care about is the words. Because they came to your site to complete a task or find a piece of information, not to admire your design. That’s why you need a writer on your web team who truly understands best practices, mobile content, information flow, user behavior and psychology, content process, governance, and sustainability. Plus you need someone who can tell a damn good story.
Writing for a website isn’t the same as writing for a brochure. When someone reads your brochure, you have their undivided attention while that brochure is in their hands. They can’t leave your brochure for a different brochure. They likely don’t have 15 other brochures open at the same time. On a website, you have seconds to capture your audience’s attention and help them find the information they’re looking for. After a person reads a brochure, they’ll likely throw it in the garbage. The content has a limited lifespan. Your web content will live forever and needs to be continuously updated.
Take heart, writers. I feel for you. I believe in you. I know how important you are.
There it is. A team that can launch a website. Notice that it’s truly cross functional. In the web world, this is the only way to operate. Too many agencies isolate their developers from their designers and writers—the people they like to call their creatives. But the work developers do is also creative. Talk to a developer about the most creative solution they’ve ever come up with for a complex technology problem and try to convince me otherwise. On the flip side, your designers and writers need to be around your developers as much as possible so they can start to understand how the web works, the considerations of the people building the sites, and the different ways their work impacts the final product.
Have conversations early and often
It’s natural for developers, designers, and writers to have different viewpoints and competing priorities. Developers are thinking about structural stability, adherence to web standards, and (hopefully) usability. Designers are considering aesthetic appeal, visual consistency, and (hopefully) usability. Writers are paying attention to clarity, telling a compelling story, and (hopefully) usability.
The common factor here is usability, the true top priority for any good website. But this top priority can get muddled by any number of things. Maybe a misguided sales team that wants thousands of words to explain every feature of a product. Maybe a marketing executive that wants a bigger logo. Maybe the very developers, designers, or writers working on the web project. It’s easy to get distracted when we fall in love with our own ideas or preferred way of doing things.
But there’s a saying in the world of fiction writing, and I think it applies to any act of creation, including websites. “Kill your babies.”
But killing your babies means making hard choices. How do you know which elements of a project are the right things to kill? Certainly some ideas truly are genius and should be spared. The only way to arrive at well-informed decisions is to take all considerations into account. The only way to do this is to have conversations with the whole team on a regular basis. This will also keep everyone on the team focused on the same goal while conflict and chaos seem to be circling all around.
Yes, team conversations can be tense. Web people tend to be smart. Smart people tend to be passionate about their ideas and beliefs. Put a group of passionate people in a room, and sparks might fly. But some of the tensest conversations I’ve ever had have led to some of the best projects I’ve ever worked on. And the alternative of letting each team member work in a silo and make decisions in a vacuum breeds distrust about both goals and abilities. I’ve seen this distrust tear teams apart as members start to question each other’s motives and resent each other’s ideas.
Don’t make it a pissing match
Agencies are full of egos. This can be the biggest challenge of agency work. I don’t question the validity of the egos. A lot of people who work at agencies have paid their dues. They work hard. They’re really bright. They’ve earned their spot at the table.
I also don’t see a healthy ego as a bad thing. I have an ego when it comes to my profession. I’m confident in my abilities and creative output because I’ve put in the time and effort to get pretty good at the work I do.
But oversized egos make collaboration damned near impossible. And checking your ego at the door can be really hard, especially when someone does or says something that seems to challenge or contradict you in an area where you consider yourself an expert.
Here’s the thing I need to remind myself: I’m not always right. I don’t always know best. And sometimes (on extremely rare occasions :) ) a project manager has a great idea for a storytelling direction. Or a designer comes up with a great headline. Or a developer has an idea for structuring content that will make it much more useful for visitors. I need to be able to recognize good ideas when they present themselves, and sacrifice my own ideas for the betterment of the project. This is an extremely difficult thing to do, but extremely worthwhile.
Let people do what they do best
Once you’ve checked your ego, you’ll be ready to help the people around you reach the pinnacle of web team greatness: let the people on your team do what they do best. Encourage them in their expertise. Show them you trust them and their decisions. Tell them when they do something that knocks your socks off.
Team members build trust when they support each other in their creativity.
This means I need to understand that, while I might have a design idea every once in awhile, I’m not a designer. So I need to defer to the designer on the project and avoid the temptation to prescribe too much of what I think a website should look like. If I want to make those decisions, I should switch careers and be a designer. Likewise, I hope others on the team would defer to my expertise on content. I don’t mean that we should always keep our mouths shut or push each other to get better. But once you’ve established that you respect the expertise of your team, you can have much more constructive and valuable conversations about reasons for doing things a specific way, or alternative directions for a piece of content or design element.
I specifically call out design and content in this section because those are the two areas most open to ridicule in the review phase of any web project. I don’t see too many project managers or organizational leaders questioning the code of a site (largely because they never see it and couldn’t understand it if they did). But they think, because they can read and write emails, or because they have favorite colors and take photos with their phones, that they’re creatives who can contribute to the visual and content elements of a site. It’s important that you let the people you hired to build the website do the work they love.
See, that wasn’t so hard. Four simple steps to making web projects great.