There were a few articles doing the rounds recently that touch on some deep, fundamental, aspects of modern day web development. They had some common themes: the importance of being flexible and that this stuff is hard (developing for the multi-device world). We’re still finding our feet, and one area that’s seeing lots of change is deliverables.
Given the fluid nature of the web, what are the right deliverables for designing and building a web site? How can we show work in progress on a web site without showing the whole, fluid, web site? Whose job is it to decide what we show, how many deliverables there are, and to explain why they’re different from “traditional” deliverables?
Jeremy Keith’s Continuum and Ethan Marcotte’s response: Platformed both discuss the squishiness and universality of the web. Jeremy pointed out that despite the fact that there are differences in browsers and operating systems we can still support every browser that can connect to the internet by using a strategy of Progressive Enhancement.
the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.
you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.
He points out that it’s our responsibility to explain this diversity of consumption of the web, to educate clients who don’t understand.
Explaining your design work is part of your design work. It’s the same with web development.
Mike Monteiro often talks about this, too: What Clients Don’t Know (and Why It’s Your Fault). Ethan added to this, saying that because of the fluid, chaotic, nature of the web as a design medium:
we play the long game in this business.
The next day I picked up Laura Kalbag’s excellent article: Delivery Logistics, on A List Apart.
In web design, the deliverables we create are rarely the final product; they’re rarely the thing we’re going to “put live” to any users.
We need to stop acting as though deliverables are the be-all and end-all of web design, and treat them as the communication tool that they are.
This is really important. Style Tiles are an excellent example of this. They provide provide a catalyst for discussions: interface elements without layout, so that we can focus on pieces that make up the design and the layout. The deliverables along the way are essential to the process: we’d never make it to the end, or build the right thing, without things like Personas, Customer Journey Maps, Style Tiles, and so on. We should be treating them more like signposts to the end product than the end products in and of themselves, though.
Even the web site (the “real” deliverable), once it’s gone live, is in a state of flux: content gets updated and moves or breaks things; styles get updated for new branding elements.
It’s an ongoing process of discovery and learning. One thing I do know is that, as an industry, our tools need to keep changing to keep up.
Building a mobile and a desktop prototype and testing them extensively is great (and very practical), but it’s important to remember that these are just two very thin slices of how the site will be experienced: browsers accessing the web have a lot of dimensions to consider. More on that soon.
Of course there’s a balance to be had. It’s impossible to test across every configuration, and impractical to test across large numbers. It’s also true that many of the lessons learned at these two points on the spectrum can be applied widely. I think that it demonstrates the importance of getting into testing with browsers earlier rather than later, though.