This week I’ve been in Nottingham working with the team at Kind on a freelance gig. What’s particularly interesting is that this is the first project I’ve worked on that’s been styleguide-first—so before a single mockup is visible in the browser we’ve normalised the design into a programmatic language, written clear documentation for developers and considered the many various ways in which this codebase might change over time. It also forces me to write that code to a much higher standard than I might otherwise.
At the moment we’re using a fairly customised version of Hologram to help us plan this system of front-end components and I’m sure we’ll be sharing the final design at a later stage. Here’s what it looks like right now:
The menu at the top displays all the different types of component and I’m still not happy with the naming conventions as I really dig the namespacing idea that Harry Roberts described earlier this month. But anyway, we have the name of the current breakpoint in the top right which is useful for debugging things. And one really useful part of our styleguide is the ability to add a renderer that appends
contenteditable="true" to the markup of an example. This is handy if we need to double-check the line-height of a heading, for example:
Styleguide-first design and development makes sense for a host of reasons, most of which I tried to outline in my talk last year. I’m not sure I did a particularly great job at the time but there was one theme that emerged which still interests me:
I wish I took a closer look at this idea back then because the slide makes it sound kinda self-helpy. What I was trying to say was that a website is a service for users (it’s a tool that changes over time) but it’s also a service for designers and developers (they have to keep coming back to the codebase and making adjustments). This is what makes a website different to a book or a newspaper or television.
gov.uk is one excellent example of a website as a service.
One reason why a styleguide is an invaluable asset for those services is the way it immediately sets up the team’s expectations. The designer must make compromises for the sake of normalising the system programmatically whilst developers are forced to acknowledge that their shitty code just won’t cut it anymore. They have to think beyond whacky hacks and short-term tricks.
Perhaps I’m preaching to a very bored and unenthusiastic choir, so I apologise if you’ve heard this all before, yet I feel that this cant be the case when I see lots of folks still calling themselves product designers without a hint of sarcasm. All their beautiful, pixel-perfect products are merely next year’s half-assed, poorly implemented services that another designer and developer must unfortunately inherit.
What it comes down to is this: there are no products on the web. It’s services all the way down.Reply via email Random post