5 minute read
You cannot design for the web unless you understand your medium.
Early in my design career (before being tempted into this 'web' thing) I did a lot of design for print. Catalogues, brochures, stationery, packaging, marketing swag… If you name it, there's a strong chance I designed one.
The world of printing can be a little terrifying for the uninitiated. Document standards. Paper finishes. Bleed. Resolutions. True black. Crop marks. Colour profiles. Ink types. The list of possible 'gotchas' is seemingly endless.
Of course it's possible (and tempting) to stay firmly buried in your design tool of choice and ignore all of that complexity. Your printer can just use some kind of standard stock, and if it doesn't look quite the same as the design, well, hopefully the client won't care too much.
Of course, the best print designers don't leave any of these details to chance. You get one go at printing, and you sure as hell don't want to screw it up. Instead of leaving those implementation decisions in the hands of the printer, it pays dividends to be there every step of the way. Visit the print studio. Feel the paper options. Discuss the finishes. Create prototypes. Get insight from the experts. For a designer navigating the complex world of printing, none of these tasks are a waste of time.
Hopefully the similarities between print and digital products are obvious. As digital product designers we operate in an environment that is just as complex as print — perhaps more so. For us to successfully navigate that complexity, we have to engage with it rather than ignore it. Our interest in the product shouldn't end with a pixel-perfect Sketch file; we should care deeply about the living, breathing, end product that our users ultimately interact with. How it looks and feels in different viewports, how interactions are handled, how load-times affect the experience, how accessibility requirements impact the design, source order, error states, that weird edge-case that your app can find itself in when a user does something entirely reasonable but unexpected…
Surely it's preferable for product designers to anticipate these challenges ahead of time, rather than having a mad panic during implementation when these issues come to light? Filling in gaps at the eleventh hour is both inefficient and risky. If it's within our power to mitigate problems earlier, it seems unprofessional to pass up that opportunity.
15-20 years ago, the web we were designing for was a very different animal. A clear delineation between design and code was much easier to live with in a world without wildly varying screen-sizes, less emphasis on accessibility, and simpler applications. After two decades of evolution we shouldn't expect to be working in the same way.
It's worth acknowledging at this point that no two development teams are alike. I've been very fortunate in that I've been given a licence to ship code for the past eight years. If I see a design issue I have the power to improve it directly without waitng for engineering resource to become available. However, if you do find yourself in a more siloed environment, that doesn't mean that you're powerless.
At the very least, try to develop an interest in the technology your engineering team is using. At the lowest level, that's likely to be HTML, CSS, and some form of Javascript. If you can go beyond that and get an understanding of the rest of your team's tech stack (React? Rails? PHP?) even better.
Then there are the engineers themselves. Work closely with them at every stage. Get used to talking through early-stage designs with them. Be inquisitive and try to gain an understanding of how they work. In 15 years of doing this job, I've yet to find an engineer who isn't happy to explain things to a designer who's keen to learn.
If venturing into the world of development seems a scary prospect, don't worry. We all had to start from scratch at one point. But begin to chip away at that mountain of knowledge and the results will be 100% worth it.