Tag Archives: process

Getting to Forest Height

I’ve just gotten back from a lovely vacation, spending some time relaxing and away from the pressures and day-to-day of work. While the vacation glow persists for another day or two, it got me to thinking about the tremendous value of just stepping back for a bit.

It is a truism that we often miss the forest for the trees; that is, we get so enmeshed in the detail of things that we can miss large-scale trends or broader context. That’s not to say the details aren’t important — in fact, in terms of execution, they’re incredibly important — but in isolation, they can be crippling.

Getting even just a few days away from the current project can be helpful to come back to it with fresh eyes and a fresh perspective. New approaches are more obvious, as are (more importantly) new questions: Why are we doing it this way? Are we really on track to meet the intended needs? Does this all still make sense?

The tech world mythologizes the start-up work environment where everybody works 20 hours a day and sleeps in their cubicle (or works around the clock from their bedroom). There are times when that may be necessary or desirable. But I’d submit they are pretty few, and if they’re not interspersed with time for recharging and replenishing both cognitively and emotionally, you may end up confusing motion with progress.

When Is It Done?

When you’re working on a development project for a client, it’s often pretty easy to figure out when you’re all done with it.

After all, you did a requirements document before you started, right? So you know you’re done when the requirements are all met, and the client is happy. Easy peasy.

But on a design project, it’s not always so easy. There’s always something more you could tweak. One more adjustment to that logo, one more look at the spacing on that text. Where does it all end?

Well, on projects where we work by the hour, we usually apply what we call the 90-10 rule. If the last 10% of minor fiddling is going to take lots of time and be virtually invisible to the client, we stop at 90%. Then, when we show options to the client for feedback, we review what additional things we could do (and how much time they’d take). That way, the decision is the client’s.

But on projects where we have a flat fee, it’s a little tougher. At some point, there’s a diminishing return, but when you’re immersed in a project, it can be difficult to see it. So as designs are nearing the end stages (before getting final client sign-off), we do an internal review, and have a discussion about what’s where, and what could still be done, and figure out if it makes any sense.

These discussions are often spirited, and also often lead to great design outcomes. We do it on the dev side, too, but usually earlier in the product cycle.

It can be difficult when you’re head is down on a project to see that you’re done. That’s why we rely on others to help.

When Things Go Wrong

When a new relationship is starting out, things are perfect. Your prospective suitor is shiny and new, and you spend time getting to know what each other likes and dislikes, how they like to do things. Whether that exploration is over long meals, coffee dates, movies, whatever — that exploration is part of the joys of dating.

After a while, though, sometimes the relationship hits a rough patch. And the getting-to-know-you part of the relationship plays a huge role in whether or not it survives the rough patch. Did you learn the ways that you each like to communicate? Did you work on solving problems that were small before something bigger came along? Do you have a depth of history together that can help you weather the storms?

These are all similarly felt in a strong business relationship as well, of course — although there are fewer movies and dates.

When we start talking with, and working with, a new client, we spend time understanding how they work, what is important to them, and how they communicate. We talk about how to keep the lines open, to address small things before they get big. And if small issues do come up, we try to get them resolved as quickly as possible.

But sometimes, bigger issues do appear. It is only through these preliminary steps of understanding, though, that we build a strong foundational relationship that carries us through these conflicts.

When we talk with other agencies and contracting firms, we find that they focus a lot on the many good things they can do (and that’s important). But they’re often more reticent to discuss what they do when there’s a bump or hiccup. If you (or they) are in it for the long haul, though, it’s worth asking the follow-up question.

It’s just a little bit of insurance — you don’t ever want to need it, but when you do, it’s good information to have.

Should Lorem Ipsum Die?

Last month, Paul Souders posted a piece that was one-part futurism, one-part opinion, one-part rant, entitled: “Content-first design ain’t herding cats.” He raises a handful of design trends and then makes leaps to what he perceives to be the best responses.

Amidst some of the all-caps and bolded pieces is the underlying premise that content should always drive design, and thus, the content should be present before the design is done. Not necessarily a revolutionary sentiment, but certainly an admirable one — sort of the web design version of form following function.

In practice, though, it seems like it’s a goal but not often the reality. Usually, content is getting reworked (or generated) as the design is being done as well. So Souders’ contention that we should “[k]ill Lorem Ipsum for good” might ignore how projects tend to work. Or at least how they’ve tended to work in our experience.

That’s not to say design drives content — quite the opposite. But often, a design framework will be in place well before the content is “done” (put in quotes because when is content ever really done?). When the content is ready to go into production, there are often tweaks and alterations to the design. But to hold one up altogether for the other would extend project lifespans considerably.

Other responses are predicated on the idea that walled gardens and Instapaper will be the primary way we view content in the future — web scrapers that take someone else’s content and puts it in their display. I’m not so sure about that future, both for copyright and commercial reasons. Big brands aren’t going to want some third-party app effectively removing their specific brand pieces (trade dress), nor will they stand for it for long, if it threatens to become ubiquitous.

Further, it’s difficult to see how the Instapapers of the world would handle more intrinsically dynamic content, where design necessarily is a bit removed from content because the content can vary.

Thinking hard about content before thinking hard about design is a good idea. A great idea, even. Holding up the design process until the dots and twiddles are done to accommodate a scaper-driven future? I’m not convinced.