How to Make the Web Better

This is the first in a monthly series prompted by Sparkbox, to start more meaningful conversations about our web industry. A new topic is announced the first Monday of every month, and on the last Friday of the month, everyone taking part in the monthly topic will post a link to their article with the hashtag #startYourShift. This month’s topic is “How to Make the Web Better”.

I almost didn’t write this—I put it off while making myself busy with client projects and meetings, but I kept coming back to this thought of making the web better. I’ve been loudly grumping to the general public the last few years about keeping our clients and backend users in mind when building websites, and what better place to continue grumbling about this than on my own personal blog?

So how do we make the web better? We must make the web more maintainable for the people updating their sites.

We need initiate our project teams to educate clients on best practices, web standards, accessibility standards, and why these all matter. We must create better documentation for the CMSes we use within our agencies, and provide better training after the project is over. We should provide so many resources, in an organized fashion, that our client always feels like the expert of their realm of the web when they log into their organization’s web dashboard.

Mike Monteiro gave a great talk titled What Clients Don’t Know (and Why It’s Your Fault) at the Digital PM Summit in Austin two years ago. The theme of trust with clients is echoed in many writings across the web and discussions I’ve had with other project managers, designers, and developers since hearing this talk. Our clients come to us because we are the experts, and they are not. They are taking a risk working with us, they don’t know the industry or trade, and they are placing their trust in not only our skill sets, but our places of work and their relationship with us as project managers. Client-shaming is wrong, and happily, I have started to see many of my colleagues encourage empathy and understanding in our clients with our teams.

Proactive client advocacy in projects is overlooked regularly, however. Initiating the work to encourage our clients to become their own mini-experts in the web industry is hard, requires lots of education, and takes face time. As project managers with limited time and resources, we often struggle to make time for all of our projects, client check ins, and coaching team members. I cannot count the amount of conversations I’ve been a part of where I or a fellow project manager lamented being overbooked with projects and overwhelmed. Taking the time to go above and beyond project duties is a pipe dream many project managers can only complain about.

I’ve written about the incremental changes I think project managers are able to make within our industry in this article titled Grow Up!. Going beyond our own agencies and into the client space to think like our clients think and see what our clients see will take a similar skill set, but new solutions. So what do we do? We ask more questions of our clients, spend more time getting to know their current systems and workflows.

One thing I’ve started thinking about more is how to apply the idea of a Customer Journey Map to a client’s internal workflow on a site. In what way and what context does a client use all of the features available to them in their CMS? Why do they use certain workarounds, or reject the use of other features available to them? Beyond the major pain points, what are they stuck on that they don’t realize can be fixed? Getting a better sense of how clients navigate their own web space will help us become more empathetic and more effective project managers.

We can also improve client education during web projects. Many of us already try to explain best practices like responsive design, or educate clients about the basics of accessibility or performance issues on their sites. What if we went further and explained our technical choices, one level deeper than CMS or design decisions? What if we started explaining to clients the sustainability of their content within the fields and channels we decide to create for them on their sites? Would clients begin giving us more informed content architecture answers if we described to them the process we go through to decide how we break up data and content we work with?

We think about these choices within our own contexts while working—how our decisions affect the project budget, timeline, how our skill sets fit in with what is needed for the web project. We often don’t think to include the client on our technical decisions, which ultimately informs the longevity and growth of their organizations’ websites. And for good reason, because we are the experts and should retain our expert authority as long as we’re devoting our lives to this work.

But let’s not discount the importance of growing our clients’ understanding of the web and imparting a deeper sense of context into the projects we work on. Our industry is growing and our influence as technical experts in the web world grows along with it. We need to consider ourselves responsible for the education of those we work with, both inside and outside of our agencies. It begins with awareness inside of teams, but now needs to extend to our clients’ welfare. Start asking those questions, explaining your technical choices, and enforcing  documentation to better serve the users of the web that we are creating.