Mark Llobrera on how content, communication and collaboration will help you make your next site the best one yet
This article’s title aside, there is no perfect site, workflow or tool. But you can probably relate to the feeling that I have at the start of every new project: no matter how well the last one went, I want this one to be even better. To put together this piece I interviewed a group of writers, editors, designers and developers to get an idea of how they go about planning sites. Their answers surprised me.
Instead of a list of favourite techniques and tools (don’t worry, there’s plenty of those in the resources section!), a few common themes emerged: the importance of content, internal and external communication, prototyping, and breaking down the divide between design and development. Their responses indicated that teams and clients are struggling with bigger, more fundamental issues than which CSS preprocessor to use.
So this is a snapshot of contemporary web workflow, touching on familiar phases and disciplines – content strategy, information architecture, design and development – but placing those in the context of the broader themes just mentioned. There’s so much that goes into planning and building a site that it’s easy to feel overwhelmed. I hope this article will provide some new approaches to those broader issues, while also giving you new tools to test out and explore.
CONTENT IS THE KINGDOM
At Bluecadet (bluecadet.com), the digital agency where I work, my colleagues and I like to start at the very beginning: with the content itself. We focus there, before any devices and their related assumptions are even in play. It’s hard, messy work, but how you conduct your research, content strategy and information architecture sets the stage for the steps to come.
Website projects can often be derailed by complex relationships and dependencies that extend past the website you’re planning. Content strategist and A List Apart editor-inchief Sara Wachter-Boettcher (sarawb.com) points out we’re not simply dealing with a website any more: “The problem is that we’ve moved far, far beyond the idea of a website as a contained, static piece of a business. The complexity and size and interconnectedness of most organisations’ web footprint – sites, apps, intranets, web-based systems and so on – is such that the web affects the jobs of everyone in an organisation. The systems we design need more ongoing management than ever before.”
Having this in mind when you conduct your user research and content strategy will help you identify potential risks up-front, while you’re still defining the scope of the project.
Content strategy
When you’re evaluating content, ask yourself: Is this content useful? Who is this for? How often will it change? Will it vary in format or length?
Determine how the content is going to be produced. Does your client have someone dedicated to creating and maintaining content? Talk to them. Ask them how they work. You want to design and build something that they will be comfortable using, long after you’re gone.
Author, editor and content strategist Nicole Fenton (nicolefenton.com) echoed this concern when I asked her about common pain points she’s encountered with her clients. She wrote: “I see a lot of companies waste money on software when they haven’t taken the time to define their business goals, outline their editorial process or train writers, designers and engineers.”
I’ve found that many design or development problems can be traced back to content problems that weren’t properly resolved. On Bluecadet’s recent project for Lapham’s Quarterly we had to restructure two content types in the CMS because we misinterpreted how content authors would associate contributors with their articles. But because we got feedback during our content strategy phase, we were able to redesign those content types and avoid costly refactoring later.
PLAN YOUR COMMUNICATION
Communication was another key topic that came up repeatedly. Almost every single person I spoke to stressed the need to establish good internal communication patterns and reinforce them as a team.
What do some of those patterns look like? Allen Tan (tanmade.com), a designer for The New York Times, enumerated a few of the steps his team has taken to improve communication: “More meetings for consensus-building. Daily design reviews. More pairing with developers – they don’t necessarily need to always sit together, but they should have regular in-person contact.”
Tan also talked about using different modes of communication, depending on the situation: “There’s built-in time in the process to make visual and functional adjustments [once a dev has implemented a design]. But sometimes it’s easier to make the tweaks myself and then send a pull request.”
The flexibility that Tan describes can be incredibly useful and liberating for a team. Sometimes it’s necessary to meet with a teammate and work things out together, and sometimes it’s better for someone to make the adjustment, and then the team can regroup if necessary. Examine your communication paths to see if they are too rigid, or if they introduce so much friction that communication stops outright.
Client conversations
It’s crucial to establish clear expectations and lines of communication with your client. At the outset of new Bluecadet projects, we take the time to explicitly state how we’re going to work and what the client can expect in terms of communication and artefacts.
Even if we’re working with a tech-savvy or prestigious client, we don’t assume they know about common artefacts and practices. For each deliverable, we make sure our client understands what that is, and what it’s intended to achieve in our design conversations. You’d be surprised at how often the purpose of a deliverable is misunderstood. In addition to the type of deliverables, we also establish their scope (‘for this project we will produce two rounds of wireframes’). We also like to clarify what types of client feedback are most useful during our conversations.
Just as you would do with your team, establish a healthy rhythm of communication with your client. The more frequently they are involved, the more you’re able to avoid surprises, misunderstandings and lost hours.
Designer, author and ARTIFACT conference founder Jennifer Robbins (artifactconf.com) talked about some of the client communication lessons that came out of the last two years of ARTIFACT: “I think there’s a shift towards more frequent communication and more specific communication, [especially] when you’re doing the prototyping earlier on … a lot of the decisions that used to be made in a row are now being made concurrently so it just requires a different speed of communication. It just seems like more touchpoints with the client.”
PROTOTYPES
Another major theme was the emphasis on prototyping as an important tool. I asked designer and author Ethan Marcotte how his workflow has changed in the years since his book Responsive Web Design (netm.ag/RWD-264) was published, and he replied: “In my practice, the importance of PSDs and comps has been lessening. They’re still incredibly valuable, but prototypes – even rough ones – are becoming more important to early discussions around content, design and functionality.”
Marcotte also pointed out how prototypes can help set expectations for your website as a continuum of experiences for different browsers and devices: “I try to incorporate devices as early as possible in design reviews. It does a great job of reinforcing that there’s no canonical, ‘true’ version of the design.”
A few designers have created modular, component-based deliverables to replace (or supplement) the full-page comp. Style Tiles (styletil.es) and Element Collages (netm.ag/collages-241) are two notable ways of giving detailed components (for example: a callout block, a navigation button, a headline and paragraph) enough context so they can be evaluated.
These approaches focus the design conversation on the system or element level, as opposed to a static, fixedwidth page. This can lend itself well to the responsive conversation, because responsive sites are fluid, instead of being locked to a definitive size.
Even with these systems, however, a client will often expect to see a fullpage comp, and you may have to decide whether your team is more comfortable showing them that via a static comp or through a prototype.
DESIGN MEETS DEVELOPMENT
On many teams there’s a hard division between design and development. It’s time to start punching holes in that wall, and getting the teams to dance. The focus of your team should be on amplifying each other’s strengths, as opposed to getting people to do everything well.
At Bluecadet we often run static design iteration in a parallel track with frontend style guide development, pairing a designer with a developer. We usually create these style guides as a single page directly in the target CMS of our choice, but we’ve also experimented with tools such as Pattern Lab (patternlab.io).
We rely on quick iteration in static comps to make sure we’re headed in the right direction, and then we test those assumptions in a responsive context using a frontend style guide. The style guide will reveal limitations in the design, and we can decide whether to iterate in Photoshop or just adjust things directly in markup and CSS.
A bonus to this design pairing? It demystifies the work on both sides. Designers can see how editing CSS can change styles across the entire site, and developers can understand the specific decisions behind a design.
SITE SEAWORTHINESS
One of the tricky things to do is to balance testing with development, especially if you are building your website using progressive enhancement. This means making decisions about which browsers and devices receive a baseline – but content-complete – experience, and which get optimised to take advantage of the latest CSS3 and JavaScript features.
My advice is to make device testing a part of your regular team meetings. My process usually involves testing on a few common devices during sprints, then expanding to the full suite during weekly meetings. The more frequently you test, the fewer hours you’ll have to put in later.
For testing your responsive designs, there’s no substitute for using real devices. Adobe Edge Inspect (creative.adobe.com/products/inspect) allows you to synchronise devices to a master browser, so that you can check multiple devices with ease. We keep a range of devices on hand at the Bluecadet office (older Android 2.2 phones, Android tablets, and varying iOS devices running iOS 6-8). If you don’t have a collection of devices for testing, OpenDeviceLab.com (opendevicelab.com) can help you find a device lab nearby.
If you’re looking for remote testing, BrowserStack (browserstack.com) and Sauce Labs (saucelabs.io) both give access to a wide cross-section of operating systems and browsers. Testing in this manner can be slow, so I’ve found it more useful for quick rendering checks, as opposed to testing interactivity.
Performance planning
Performance is something that directly affects the bottom line, but as an industry we often treat it as a separate consideration that we do after everything else. One of the lessons I’ve learned is that it’s a lot harder to optimise performance if you haven’t considered it up-front, so establish a performance budget at the outset.
This could be a limit on the total page weight for any given page of the site (650KB, for example), or a timedriven aim (7s total load time on a 3G connection). Tim Kadlec has been writing about performance budgets for a while on his blog (netm.ag/kadlek-264), and Dan Mall recently wrote about how to make one (netm.ag/budget-264).
If you’ve prioritised performance, the next step is to measure and optimise for it. I prefer to use WebPagetest (webpagetest.org) and Google’s Page Speed Insights (netm.ag/insights-264) to diagnose and optimise my sites’ performance.
ALL TOGETHER NOW
Researching this article revealed two parallel, complementary threads. On one side, our tools are better and our techniques are adapting to the increasing range of devices and browsers. That’s the straightforward part: exert enough brainpower and technology, and you’ll eventually reach a solution.
But there’s another side, and it’s equally important. Creating a site today requires better internal and external communication and collaboration. We still need to face our old, familiar content problems – they haven’t gone away, they’re just magnified by the multitude of ways in which content can be delivered and consumed.
If you’re like me, you might be tempted to lean heavily on that first side, and focus tightly on the fine-grained details of design and development. And that’s fine, to an extent – you can actually make a pretty good site by ensuring that the craftsmanship in your discipline is topnotch. But I think if you’re really going for it – if you’re reaching for that elusive, perfect site – you should pay equal (if not more) attention to the details outside your discipline.
That might involve putting yourself in your teammates’ and clients’ shoes more frequently, or tweaking your team’s tried-and-true workflow to make it better. And if that sounds like a call for more empathy in design, that’s exactly my point.
Finally, sharing your experiences is absolutely essential – the web does not stand still, and we depend on each other to push and pull ourselves along with it. Finding and sharing the good and bad parts of your process helps everyone, because our community has shown time and again that we can solve problems – and make better sites – together.