I think specialization is detrimental to building websites.
Throughout my career, I’ve mostly been called a Developer. I’ve worked with other people called Developers, and people called Designers, and people with other very specific titles like Project Manager and Content Strategist and Quality Assurance Analyst. We each have our particular abilities, the kinds of work we’ve honed into expertise, but the edges of this work are always fuzzy. When we’re building websites, they are made of, and with, all these kinds of work in nearly equal measure.
This is a pattern I see over and over:
This pattern generally plays out in this order, linearly. Product hands off to Design, Design hands off to Development. If we’re lucky, people who are experts in some of those other disciplines get to focus some energy as well, but they often need to squeeze into the cracks. There is sometimes some cross-collaboration—maybe an early brainstorming kickoff session, or a shared research phase—but mostly the work moves from one group to the next. We’re all in our lanes, trying to keep tabs on each other in our peripheral vision. But it’s all one road. We’re in separate cars when we should be in one bus.
In this linear, bounded process, time and again, so many details are left undiscovered until it’s too late to do anything with them. Some of those details are bad: weird combinations of interactions that no one considered until they saw them fully working; complicated UIs that don’t work with touch, or on small screens, or for screen readers. The bad details either demand a hasty, sloppy addition, or they are deemed admissible and stay bad. Some of those details are good: interesting potential combinations of interactions, an accessibility tweak that makes the content structure more clear for everyone. Usually these good details are dumped in the backlog and stay there forever.
I think there’s a better way. It’s not revolutionary; it’s something most of us already do with our teams to some extent. It’s iteration! What I think we seldom do, though, is commit to iteration all the way through, in the product but also in our individual responsibilities.
A really effective team is composed of a small number of people who have some amount of aptitude in all the disciplines it takes to build a website. Each person need the systems thinking and platform knowledge of an engineer, the user considerations and critical eye of a designer, the contextual insight and practical philosophy of a product manager, the clear communication of a content writer, the skeptical eye of a tester…
Not everyone should be expected to be an expert in all of the things they’re doing—and it’s good to build a team with balanced expertise—but it’s important that everyone has some understanding of every part of the process, and is involved in every part as well. A small team in this style is often called “cross-functional.” I’m instead suggesting that each member should be cross-functional.
At the start of the project, everyone gathers requirements together and starts to imagine what the end product might be. Begin with abstract concepts. What are the most important words on the most popular page? What are the things a user is reading, or sorting, or manipulating? How are they organized, and how do they relate to each other? How might we present them to the user?
Now get something into the browser! Conversations should quickly transform from abstract notions to concrete interactions. Accept that anything and everything can and will change, and start building anyway. Even if you’ve just set up your CMS and the content you enter doesn’t show up anywhere, start entering it. It’s important for the whole team to internalize the whole process, as administrators and as users. If you simulate this process with prototypes and mockups, you’re bound to forget important things. Avoid lorem ipsum—choose real words, now. You can change them as you hone the thing you’re making, but you need to figure out what it is first.
It can be hard to get stakeholders to trust in a process where the first thing they see might be grey boxes, or unstyled text running down the page. Even a very anxious stakeholder can find comfort in a plain page full of text if they can understand what the page represents. Helping them understand is part of the job, too.
I don’t think it’s a good use of your team’s time to consider static assets—wireframes, mockups, even clickable prototypes. I think that in the world of websites, these kinds of assets are dangerously inert. They can never account for the variety and mixture of content and viewing environments that arise on a real website. They won’t stay up to date as things change. (A website is not a series of pages; it’s an interlinked system of interactions.) These sorts of assets might be useful in conveying specific ideas within the team, but keep them short-lived: demonstrate an idea, execute that idea, throw out the asset. And never show them to your stakeholders.
The thing you’re iterating on is the experience, in its entirety. This includes content (what users will receive) and accessibility (how they’ll receive it). It includes design and development. It probably also includes Javascript and component libraries and logos. But each of these is just one ingredient. Defining and exercising the experience is most of the work, and everyone on the team has plenty to provide.
Finally, the experience reaches a level of fidelity that really could be put in front of your audience. It might be a little clunky, it might be a little ugly. The fine tuning in these final iterations is where the specialists in every discipline get to shine at last. Designers can design and Developers can develop. When you get here: congratulations! Until then: stay on the bus!