Prototyping Your Workflow

Last year the digital agency I work for, Bluecadet, started a website redesign project for The Franklin Institute—a renowned Philadelphia science museum undergoing the largest expansion in its history. My colleagues and I were excited because not only were we getting to work with an iconic local institution, but the project represented an opportunity to incorporate a number of techniques into our responsive web design practice: atomic design, HTML wireframes, style tiles, element collages, and front-end style guides. We envisioned a series of quick prototypes that lent momentum to a harmonious back-and-forth between design and development. We felt like this was an opportunity to overhaul the way we created for the web, from start to finish.

Article Continues Below

And then we got stuck.

We couldn’t figure out where we would fit all of these new techniques into our preferred way of working. I don’t think we’re alone in this. The way we create for the web is changing so rapidly that if you’ve attended enough conferences or read enough books and blogs these last couple of years, you may feel like we did: excited but a little overwhelmed, and worried that your organization is the only one that hasn’t yet adopted the expert-approved way to create for a device-agnostic web.

There’s a seductive danger present whenever you see someone else outline their way of working, however. It’s easy to take their process as a rigid, universal truth. The trouble is, you and your team aren’t like everyone else—you have different strengths and weaknesses. Borrowing someone else’s process wholesale ignores the fact that it probably took them lots of fumbling to get to that point, and it’s going to take plenty of experimentation on your team’s part to figure out what works for you.

So perhaps the solution isn’t to transplant someone else’s guidelines in an attempt to fix the entire thing all in one shot. Maybe there’s a way to take the same iterative spirit of these new techniques and apply it to the overall workflow itself. To prototype your workflow, in other words. In some ways, it’s a mental trick—a way of giving yourselves permission to try things, even if you’re unsure of the outcome. It also lowers the stakes to a comfortable level: if we mess this up, we’re still okay.

What follows, then, isn’t a tidy recipe or a formula. It’s a collection of observations I hope will help you re-cast workflow change as an ongoing process of small, imperfect steps.

Technique is easy, talking is hard#section2

It’s easy to get fixated on the benefits of specific tools and techniques, and to assume that those benefits are self-evident to everyone. But over the course of the past year, it’s dawned on us that meeting the demands of our multi-device web is less a problem of technique, and more one of communication. Sometimes people just need to understand why you want them to change how they work.

Prior to the Franklin Institute project, my colleagues and I had been pooling all of these new techniques, but we instinctively focused on pieces that affected our part of the process. Designers and developers were talking and dreaming—but largely within the echo chamber of their respective disciplines. So when it came time to kick off the project, we had to have some hard conversations about how new techniques would work for us as an entire team, and sometimes we were downright skeptical of each other’s suggestions. On more than one occasion we asked each other: “That’s great, and it works for that agency, but how would that work here?”

You will probably need to make your case differently for each person on your team, then. If you’re a designer, it could mean explaining to your developer teammate that you would like to start breaking things into a design system so that you don’t have to do 20 different iterations of the same page layout. For developers, you might have to convince your boss that a style prototype will be the best way to present a site to your client.

Whatever the rationale, realize that change represents a very real cost (at least in the short term) to your teammates’ time and comfort, and their skepticism may be their reaction to that cost, rather than to the less-immediate benefits you say will follow. Focusing on the why instead of how can help balance those two competing forces.

Limit your focus#section3

As of this writing, Bluecadet has 22 full-time staff members. That’s just big enough to make it hard to work on intricate, shifting process details at a company-wide level. So we’re starting small, at the project level, instead of trying to craft a monolithic process that gets handed down from above.

Look at the projects you have on the horizon. Think about the portions of your workflow that you want to improve, and pick just one of those things to introduce into your project. Why just one? It allows you enough space to experiment without endangering your project.

A mentor of mine once told me that programming (and especially programming for the web) boils down to reducing the number of “unknowns” on a project to a manageable number. One is fine, two is a stretch, and three is asking for trouble. If you think exploring HTML/CSS wireframes could have a positive impact on your work, introduce just that one thing. Most projects have enough built-in friction without adding or changing multiple processes at the same time.

For the Franklin Institute project, we ended up deciding that the added wrinkle would be a front-end style guide. It wasn’t the biggest thing, but it was one small step that we thought could have a big benefit without affecting our schedule.

We made this decision based on two factors—factors that might be helpful as your team thinks about what that “one thing” could be:

  • A good idea that didn’t quite work in the past: we had created a static style guide for a previous project that had quickly become outdated and was ultimately discarded. But we still thought the idea had merit. So when you gather as a team, think about past good ideas that might have stalled, and whether they could work if you approached them differently.
  • (A little) experience mixed with (a lot of) enthusiasm: a new front-end developer joined our team, and he had already been experimenting with different style-guide generators like Barebones and Pattern Lab. More importantly, he was excited about building one. Does someone have something they’ve been testing on a personal project, or that they’ve used successfully at a previous job? If so, you’re already halfway there—you might just need to figure out how to make space for it.

Align your tools and techniques with your team#section4

One of the recurring discussions we have at our studio is: “Should our designers learn markup and start doing some of this design in the browser?” We’ve heard a lot of persuasive arguments for it, but in the end, we decided that the main focus should be how to get our designs into the browser earlier in the process, instead of who should be doing that work.

This led us to try pairing designers and developers early on in a project, and having the developer create markup that “waterskis” behind the designer’s sketches and Photoshop explorations. We’ve found that doing it this way takes advantage of our team’s individual strengths. It also means that our developers are providing feedback that makes it into design iterations while they are still malleable.

We’re currently in the middle of a redesign project for a literary magazine, and we’ve found that the rough HTML/CSS mockups created by our developer helped us pose the right questions to our team’s designer. Giving our designer a specific problem to solve (“These titles take up too much space at narrow widths”) allowed her to judge the problem in the context of the entire design. She could then explain what she was trying to accomplish visually, and even find solutions that extended beyond the immediate issue we were trying to solve. She’d look at the screen while we squished the browser back and forth, and then say something like, “If you move the titles below the photos this whole problem goes away.” Stepping away from dogmatic ideas of who should be doing what allowed her to focus on doing what she did best, which was solving visual problems.

Distinguish between internal and external needs#section5

When you start moving things around, you may start producing deliverables that are important, but only for an internal audience. That might be because they’re of limited use to the client, or they simply may not be mature enough. Managing expectations is as important as trying a new technique, so if the client is going to see something new, you’ll have to invest time preparing them for what they will receive—especially if it’s not how they’re used to working.

For a current project we are producing HTML/CSS wireframes to get an idea of how long they actually take to make. Since we don’t know (yet), the first rounds of client deliverables are still going to be static wireframes done in Photoshop. If we feel like the HTML/CSS prototypes are mature enough, we will introduce them to the client in the final round.

As you work, then, give yourself enough room to adjust: what if it takes twice as long to produce that wireframe? What if the client is resistant to parallel wireframe and design conversations? What if the thing you’ve produced has value, but only if accompanied by other deliverables?

Focus on products, not presentations#section6

One of the things we’ve had to do was clarify the ultimate goal. This seems obvious: “We’re making a website.” But if your process is anything like ours, you actually spend a lot of time making anything but a website. Mostly you make pictures of a website.

Recently, while working on a beta build of a website, we found out that the majority of our client’s team members were using older versions of Internet Explorer and Firefox. Those people were surprised to see something that differed from the comps they’d been presented earlier in the process.

That experience taught us a lot. Setting client expectations is one way to avoid those surprises, but we’re also slowly agreeing as a team: the browser is the final arbiter of what we do, so let’s stop shoving it to the end of the line. The components of our process need to support the final product at every step of the way.

Put your process prototype on the agenda#section7

It’s easy to nod and agree on something: “We’re going to do this!” But when you get immersed in detail work, it’s just as easy to forget that one new thing you all agreed to put in the mix. So task someone with making sure that you revisit your process prototype repeatedly. This might mean you start meeting more frequently. We’ve found it helpful to have official meetings, but our hope is that eventually we start doing this in a less-structured way, choosing to meet informally when we feel the need to discuss something.

If you’re working on a project-based team, remember to share what you’re doing with other groups. For example, on a recent project, we implemented modular content blocks that could be reordered as needed, inspired by a post by Christopher Butler of Newfangled. We then showed what we were doing to a colleague, and she integrated some of what we learned into her next project. She also had some incisive questions for us that helped us improve the content-authoring experience for our client.

By sharing with others, everyone wins: your colleagues will pick up your new skills, and you’ll be forced to clarify your goals and assumptions.

Iterate your workflow (play the long game)#section8

When you’re reworking your process, it’s good to keep a running log of the things (both good and bad) that you encounter with each new change you introduce:

  • Did something take more (or less) time than you expected?
  • Were there people who were negatively affected by the change?
  • How did the client react? If you’ve worked with them before, were they receptive to change?

By breaking things into focused pieces, you’ll be able to evaluate how effective they were. You can keep the stuff that worked, and refine (or throw away) what didn’t. Having a forum to share those pieces is important, too—at Bluecadet, we’ve made sharing lessons from completed projects with one another a regular part of our monthly all-staff meeting.

Over the course of three separate projects, we’ve now field-tested:

  • Atomic/modular content and layout
  • Front-end style guides
  • HTML/CSS wireframes

Here’s the thing: each of those things that we tried? We’ll probably do them just a little bit differently the second time around, because of all the data we gathered from the first go-round. If we had sat around until we were sure about The New Way of Doing Things, well, we’d still be sitting around today.

One of the things I’m most proud of is that by working piece-by-piece, we’ve pushed our workflow forward while being honest with our clients. One of our internal guidelines is that our clients shouldn’t be bankrolling our workflow remodeling project—our fine-tuning should result in tangible internal benefits for us, but, more importantly, a better product for our clients.

Try something new, now#section9

As I finish writing this, we’re trying out yet another thing that we hope to add to that list: HTML/CSS prototypes as a design deliverable. Maybe they will replace static comps, or simply accompany them—we don’t know yet. But it’s okay that we don’t know. By the fall, we’ll probably be building things far differently than we are right now, informed by the experimentation we’re doing piece-by-piece along the way.

I hope that this encourages you and your team to take some small steps, too. Get together and talk about the parts of your workflow that can be improved, pick one thing to try together, and figure out where you can make space for it. Like us, you’ll probably never be able to draw a line on the calendar and say, “That’s when we started doing things the right way.” But you’ll find yourself much further along—one thing at a time.

9 Reader Comments

  1. Over the past few weeks, I’ve iterated over several live styleguide generators, frontend frameworks and the search keeps coming down to the same point. What works for you is what you build yourself. It has to be a distillation of everything you have learnt so far. Borrow ideas from all over that resonate with you but build something that works for you. Iterate on it and evolve it as your learning evolves. Its an amazing time to be a frontend developer. We are all very privileged.

  2. Still hoping for the day when we can design one website and have all the browsers and devices adjust to it, not the other way around. Sick of the tail wagging the dog.

  3. Great, great article. Sometimes, as a “Little Guy”, I feel overwhelmed by the confidence that the “Big Guys” show when talking about their methods and techniques. I always feel one step beyond. I’ve just started to realize that not all of their processes fit my way of doing things and, not only that, maybe I could teach them a couple of small tricks that I’ve learned over the years.

    The biggest lesson when implementing new workflows, though, is that motivation is useless. We get motivated and excited 20 times every morning by new tools and ideas. At the end of the day, motivation has faded and what’s left is perseverance and good habits. Those are the skills to take care of.

  4. This article describes perfectly well the situation that I’m finding myself in for the last 1-2 years. It’s simply good to read that I’m not the only one struggling with it. Furthermore it’s helpful to read about approaches to a solution to change exactly that situation. Thank you for giving me a hand.

  5. Mark, this is now my favorite article on a tough topic: design workflow. You nailed it!

    The solution isn’t for a team to embrace a pre-defined way of working because it’s *the* best way to work (today.) It’s about a team learning the art and science of change management and self-improvement. And how a team goes about doing that as a unit is going to be different for every team. It’s ultimately about leadership (a.k.a. influence), and you’ve set forth a very humble and effective style of leadership for design teams. Well done.

    I also appreciate that, although you’re writing from an agency perspective, this entire article works just as well for in-house, corporate web / application design teams, too.

  6. @Ulf: One of my main reasons for writing this was to encourage people. I’m seeing a lot of great responsive/device-agnostic work being created out there, but a common theme I’m also hearing is that the steps/process to create that work are big pain point. That discomfort exists on both sides—both web professionals and clients feel it to differing degrees.

    @Ben: Thanks for the kind words. Changing individually is hard, and gets harder on a team level. I think it’s good to remember that these changes take *time*. But that’s probably a good thing, because that time can also allow you to smooth out the rough edges as you try new things.

  7. Vi have been doing something like this at my digital bureau Peytz & Co for about half a year now. It was a bit of a leap of faith. We have stopped using wireframes and photoshop comps as deliverables.

    Now we do textual (bullet listy) content and flow descriptions. Greyboxes of the overall site-structure. A brand and identity focused look & feel visual delivery. And then it’s straight into prototyping.

    Some things are more difficult. Some things are much easier.

    Overall, it’s wonderful to get rid of Wireframes and PS Comps as deliverables, that the customer must sign off on. Because many customers don’t understand these, and they quickly go out of sync.

    Key learnings:

    * Treat frontend as an iterative design process. Your frontenders must be somewhat chaos-resistent. This is now a process that involves customer feedback and lots of it. You can’t plan and beeline for the beautiful markup without interruptions.
    * Visual design can be integrated later. Do the basic identity and a visual toolbox of the main components. Then plan to create more visual components later, as the prototype develops. You don’t know what you need when you start.
    * Do a couple of pages and iterate on these. Then do a styleguide. Iterate with customer. Do the REST of the pages until 80% of time has been burned. Then polish.
    * Built your prototypes with real content from the clients existing site. It makes a HUUUGE difference. Frameworks like middleman can handle this. Being able to reload and see the same page with a variety of real content is so helpful.

    It can heartily recommend trying this approach.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA