This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
At the turn of the year, my friend Frank unveiled a lovely responsive redesign of his already-lovely website. Frank’s an inspiring chap, not least because he can turn a phrase, and just so. In fact, there’s one line from his new site that, since I read it, has rattled around my skull quite a bit. Namely,
I believe one of life’s great pleasures comes from making modest things consistently well.
I love that line. Not just because it’s a stellar sentence—although, y’know, it is—but because I think it’s a wonderfully concise statement of what Frank likes to do, and how he likes to work.
In the past few weeks, I’ve been thinking about that line a lot. Because as it happens, I find myself with some availability, and I’m looking for new projects to work on. As part of that, I’ve been having interesting conversations with prospective clients: we talk about the work they’d like to do, the size and scope of it, and how I might help out. The thing I’ve found is these conversations are helpful for me: they’re an opportunity to think about the work I like doing, and how I like to do it.
I don’t think that I’ll ever have a final, unchanging answer to that question. But here’s what I’ve got so far, for right now.
I’ll start by saying that I love design patterns. (You’re shocked, I can tell.) In recent years, a pattern library has become the de facto deliverable of the responsive (re)designs I’ve worked on. And that’s helped me realize I love helping organizations talk about their patterns, and helping them make their pattern libraries as accessible as possible.
Here’s a recent example: last year, I worked with a large financial organization, whose digital team had started creating their own pattern library. In our early conversations, I noticed each member of the team had different ideas around whether a certain pattern was an “organism” or a “molecule.” The language was, in a very real sense, introducing considerable friction to their design process. And that’s not the first time: most clients I’ve consulted with have struggled to work with off-the-shelf labeling systems. Over time, I’ve found the success—or failure—of a pattern library is tied to the language used to structure it.
To put it another way: in the long term, the organization of a pattern library is as important as the patterns themselves. Maybe it’s more important, even. Because if a pattern’s purpose isn’t clear, or if the pattern isn’t easily findable within the library, then the value of that pattern quickly approaches zero.
That’s why most organizations I’ve worked with have invested time to create their own vocabularies to structure their pattern libraries1, through workshops, design exercises, and discussion. And as someone who loves design and language in equal measure, I love doing this kind of work.
I work with a lot of digital teams, on different sites, services, and products. I’ve even worked on a number of “web apps,” which is a fancy way of saying “web sites.” And on each of those projects, I’ve found I like privileging prototypes, not pictures.
In my experience, I’ve seen few things more effective than loading a prototype up on a device, and letting a client explore it. It shines a bright light onto potential issues with our work, sure—but it also makes earlier design decisions considerably less abstract. When the design’s placed in someone’s hand, and they can interact with it, question it, and use it, the design’s often stronger for it.
I should note I’m less concerned with how best to prototype. You might prefer Invision, Adobe Experience Design, or even paper and ink. Me, I rely quite a bit on Sketch, and occasionally dip into Keynote, but I lean most heavily on HTML and CSS. I do that primarily because that’s what I’m fastest with, but also because I like how close it gets me to the sundry devices and browsers we’re designing for. An HTML prototype, loaded up on different platforms and devices, often helps my clients understand that there’s no one “true” view of a design, and that we can’t always control how our design’s rendered.
But that’s me, and how I work. I really do believe the “best” prototyping workflow is the one that most closely lines up with your skills, and with those of your team. When Karen and I interviewed Virgin America for the Responsive Web Design Podcast, the design lead on the project said something similar:
…it doesn’t really matter how you get there. If you can get something that you can put in a person’s hand and get feedback, that’s the goal. However you get there is how you get there.
Now, as a designer, applications like Sketch, Illustrator, and Photoshop are still incredibly valuable to me, and to the design teams I work with. But in recent years, the things those programs produce—flat, non-interactive pictures of a website—have become far less valuable to my clients. As I said to the Source team during their redesign sprint, mockups are just the first step in the design process. Really, a mockup is where we start outlining our ideas. The design is what we actually hold. And however you get to that point is, well, how you get there.
One of the best and worst things about working on the web is, well, how little we know about it, and how it defies easy prediction. Last year I got a chance to play with an in-car browser for the first time; I also consulted on some projects that had to work on cheap, low-powered smartphones, and load quickly over sub-3G networks. The web’s evolution has never been charted along a straight line: it’s simultaneously getting slower and faster, with devices new and old coming online every day.
That’s why I’ve realized just how much I like designing in layers. I love looking at the design of a page, a pattern, whatever, and thinking about how it’ll change if, say, fonts aren’t available, or JavaScript doesn’t work, or if someone doesn’t see the design as you and I might, and is having the page read aloud to them. In practice, it often means looking at a proposed design like this:
…and designing something like this to act as its foundation:
In other words, it’s about ensuring there’s something usable in place, something that gradually enhances into the more “refined” design that you and I might see, given decent hardware, browsers, and network connections.
Trent Walton describes this as “device-agnostic design”; Frank might call this designing for the web’s “grain”. But whatever you call it, this more layered approach to design feels like the best way to prepare our designs for the adverse conditions of web, a medium that doesn’t care about preserving the quality of our work.
(I think the process is also really, really quite fun.)
Nothing above—prototypes over mockups; preserving patterns at scale; thinking about a design’s layers—is especially groundbreaking, nor is it new. But! It was fun to write, I’ll say that much. It was helpful to take stock of a few things I really enjoy doing, and to jot them down. Maybe in six years’ time—or, heck, in six months’ time—I’ll feel differently about some of these things, or all of them. But right now, this is the kind of work I like to do.
(And of course, if you like to work this way, and you’ve got a project you’d like some help with, I’d love to hear from you.)
- Alla Kholmatova, Charlotte Jackson, and Ellen de Vries have written extensively about this topic, and have been a huge influence on my thinking here; I wholeheartedly commend their work to you. ↩
This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
Ethan Marcotte | Sciencx (2017-04-19T04:00:00+00:00) The work I like.. Retrieved from https://www.scien.cx/2017/04/19/the-work-i-like/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.