Chris 14 Apr 05

This is so relevant to me right now. Thank you.

Keith 14 Apr 05

Not a surprising post from y’all, but I do have to say it’s ironic as I was just thinking about this the other day, and it’s prompted me to make some rather rash (in my mind anyway) decisions about a few projects I’ve got going.

I was feeling like I wasn’t making much progress. Why?

Getting stuck on details was one of the main reasons.

Lee 14 Apr 05

Spot on and without hype.

jarv 14 Apr 05

Funny fact - designing it’s like drawing - start with overall shape - and slowly get to the details.

isn’t it ?

anyway - good point.

Chas 14 Apr 05

Ugh. Too true. I fell victim to the over-detail urges this past week, and realized that I do so on nearly every project. Gaw, what a huge time waster when you’re trying to get basic functionality down.

David Elstob 14 Apr 05

good advice. really, REALLY relevant right now.

Lar 14 Apr 05

My one line summary of article: The Devil’s in the detail!

chuck 14 Apr 05

really enjoying the Getting Real series! would you consider providing a link to each entry in the series?

I’d like to read the series in order in its entirety as well as refer others to the the info without making them search for all the entries. Does that make sense or am I crazy? Maybe I’m missing the obvious here.

thanks

Mathew Patterson 14 Apr 05

I�d like to read the series in order in its entirety as well as refer others to the the info without making them search for all the entries. Does that make sense or am I crazy? Maybe I�m missing the obvious here.

Maybe there is another book coming…

Don Schenck 14 Apr 05

Amen, amen, amen!

(Wow … I haven’t shouted “Amen!” since I attended the Baptist church back in 1995. Thanks!)

Dan 14 Apr 05

It is too easy to get lost in the details. They can be very distracting from the matter at hand. People tend to latch onto a detail when they don’t want to (or can’t) talk about higher level issues.

At the same time, there are certain details that are crucial at early stages in the project. Particular business rules can have an enormous impact on the application.

For example, I was working on an application for a government agency. The application was meant to offer a special service for a range of products. The agency had not determined which products they wanted to include. We put this detail aside to move forward with the project and regretted it later when the client changed their mind.

You could argue that this isn’t a small detail (like moving a button 3px.). On the other hand, we judged that because the gist of the application remained the same regardless, this particular issue was small. We couldn’t anticipate the cascaded effects.

There are certain requirements that are at a more detailed level than others, and for the most part, the small bits can be set aside temporarily. At the same time the project team needs to find other distinctions to determine whether a requirement, no matter how small, is immediately relevant or not.

Benjamin 14 Apr 05

true.

Patrick Lafleur 14 Apr 05

Hi,

I really got over the “get into details right away” attitude after I took some drawing classes (I think any artistic classes can help).

If you begin to draw the details right away you can be sure that the drawing is going to suck. In fact you are completely missing the point.

You should begin by getting your proportions right for the whole scene. Then you sketch the largest objects in your scene, up to the smallest one. The sketch must be very loose up to this point.

Then you can proceed with shading which consists of bringing volume to life. You begin with only three tones (light, medium, dark). This gives you a tonal sketch. Then for each portion of your drawing you reevaluate three tonal shades and apply them. Do it until the volumes are there (requires multiple iteration).

All the phases can be resumed to this: Work from large to small. Always.

If the nose is not well proportionned or positioned in the face, you will never achieve likeness in a portrait. There’s no point to draw THE perfect nose if the rest isn’t up to par.

I apply this philosophy when I do web design and software engineering. Thank you Larry Gluck (http://www.thegluckmethod.com/)!

You should always work from big to small. And then iterate for each portion of your project (or drawings)!

Dan Boland 14 Apr 05

The hardest part for me is knowing when design elements require the details in place in order to know if they will work and when they don’t.

Richard Bird 14 Apr 05

Many designers I know, myself included, are technicians by nature. Fascination begins and ends with detail. I often find myself so mesmerized by detail that I’m unable to move forward in any direction. I call it, “analysis paralysis.”

I love the analogy someone made earlier to the act of drawing. Pencil on Canson starts with broad strokes and blobs. Gradually, layers of increasing detail are added.

And that’s exactly how it is that I approach the art of drawing a figure or a still-life - without thinking - more like feeling my way through it.

So how is it that I can’t do the same thing with my hands on a keyboard or mouse? It’s got to be the tools. We need clumsy, fuzzy tools.

Adam Michela 14 Apr 05

Patrick: Love the sketching analogy. That’s a great way to think about things…

Joshua 14 Apr 05

For me, the real challenge is the “come back to it” part. I rarely have the time or organizational support (hint, hint) to come back to projects that sorely, badly need some perfectionizing.

Scott M. 14 Apr 05

Right on, JF. Being very detailed-oriented, to a fault sometimes, I’ve learned to continually ask myself “Is it good enough?” Will this particular detail I’m working on be noticed by anyone but myself? Sometimes I’ll spend a couple hours on a detail and realize I couldn’t possibly charge the client for that time because I’m being self-indulgent and obsessed with a detail that the client won’t even notice. Sure, sometimes those details are important — it’s recognizing when it’s time to move on that’s the key.

Tom M. 14 Apr 05

I second Dan Boland’s comments on the task of determining the required level of detail.

When the ultimate goal of the project is vague, or there is no content to speak of, I seem to have a million questions for the client before I begin to design or even conceptualize. Often the client doesn’t want to hear that (which is understandable, hey, we’re the problem-solvers) and just wants to see something. So I tend to keep those questions under wraps initially and move forward in “broad strokes”, involving the client as much as is appropriate in the process, realizing that my original ideas will mutate to fit the content. It helps when the designs are open and flexible, obviously. Sometimes the client just needs to see the direction you’re going to make some decisions about content, and they tend to be passionate about what they don’t like or need, which helps you determine what they do like and need.

This isn’t applicable to all here, I’m sure. My direct involvement is at the extreme front-end of interactive/web projects (GUI design, overall page layout, etc.), so I’m sure that the many of you who both design and code have more complex variables surrounding the process, more time-consuming alterations, etc…

Kevin Tamura 14 Apr 05

Something must be in the water, I was bogged down on a project because I got caught in the details early on. When I let it go and just started playing around I made much better progress, and more interesting designs.

One of several Steves 14 Apr 05

I’ve found something to either nitpick or totally disagree with in each of the “getting real” points to this point, but not this one. You have to know what you’re doing before you can get deep into the question of how you’re doing it. And even when you’re at stage where paying attention to the details is called for, you still have to know when enough is enough. The old 80/20 rule applies: you can spend 80 percent of your time taking care of the last 20 percent of your job. Knowing when things are good, not perfect, is key to sticking to budget - and not driving you and everyone around you absolutely insane.

Rob 14 Apr 05

Ignoring the details makes a lot of sense. It can cause a lot of problems when your working on a project, becuase if you obess on the little details, you can easily become side tracked and loose focus on the bigger picture.

John Zeratsky 14 Apr 05

Richard Bird says: We need clumsy, fuzzy tools.

You’re right, we do. For me, the clumsiness and fuzziness came with time and comfort. By now, I can be every bit as fuzzy with keyboard and mouse as I can sketching something on paper. It took me along time to get here, but once I did, big changes started happening in the way I work.

And I still always have paper to fall back on :-)

John Zeratsky 14 Apr 05

Matthew Patterson says: Maybe there is another book coming…

… And if there isn’t, maybe there should be.

Bryce 14 Apr 05

I completely agree with the sentiment, but I have to disagree about ‘Getting Real.’ Every time I see it, I hear it spoken in Dr. Phil’s bombastic texas drawl…

Jake Smith 14 Apr 05

You nailed this one! I’ve learned from personal experince, if you focus on every little detail you’ll never get anywhere. It is so easy to get lost in the little things with that type of approach, that you lose sight of the big picture; the ultimate goal that led you to start in the first place.

Get the basics down, the stuff that you have to have on there, then proceed to place everything in it’s pixle perfect posistion.

Nick 15 Apr 05

I generally agree with the sentiment behind this post, but sometimes, the details are actually really important, and if you DON’T think about them early on, they can make your whole system useless…

One problem I encounter fairly often, which is requiring me to alter my approach to design, is that while I deliver systems which meet functional requirements, the code and database architecture rule out the UI detail touches required to make the thing usable, for performance or other reasons.

For this reason, I’ve found it necessary to actually FOCUS on details (not ‘which pixel’ but ‘what will it say, exactly’) to get the usability right. This is especially true when building systems to be used by thousands of people, most of which are only a little web-savvy.

my 2 cents. obviously my approach needs work, but sometimes not paying attention to details early on derails the whole project.

Bhasker 15 Apr 05

For me, having chosen to ignore minor details on projects for the last two years, is the opposition and loss of respect I encounter from fellow developers. I try to convince them that certain build / design tasks are not really important but they rarely give in without a fight - even when all my work comes in on time and to the original business spec.

Daejin 15 Apr 05

Thank you.
I’ve printed it out to remind me.

Then I stripped out the copy, laid it out in Quark, agonized over the font and an awkward line break in the second paragraph, decided I should create a template for other inspirational tidbits found on the net…
then I slapped myself.

Chris Moritz 15 Apr 05

Thanks for this. I’m working on embracing ‘satisficing’ as an operating philosophy.

Brenda 15 Apr 05

I would hope any interactive designer worth his salt would know this already. Clients, being generally naive about interaction design, want the colored, typeset, pretty stuff done first. It’s what brings the project to life for them. They know what graphics are, they don’t have a clue about databases, so if they’re going to micromanage, they’ll focus on the graphics.

But have I ever actually DONE that part first? No. Never. Not even in 1994.

Have I ever expected a site to be designed once, built once, with no need for iteration? Um… no. Have you?

Maybe the subtlety’s lost on me here, but is “big ideas first, small details last” really a new concept?

Anonymous Coward 15 Apr 05

It may not be a new concept, but it is one which many of us often need reminders of.

Paul 18 Apr 05

Brenda, more than half the stuff you guys publish on Boxes and Arrows is obvious and should be known by any designer “worth his salt.” Get off your high horse.

Huy 02 May 05

I’d have to agree with Nick above. It’s not always as straight forward as you describe. Like everything, it is the balance of focus and big picture which ends with something nice as well as successful. My point I guess is that “success” and a “nice success” is two totally different things.

Everett Lindsay 20 Oct 05

Am I the only one who feels that Ignoring Details contradicts the very first post in this series? While I have a clear understanding of the division between interface and “details,” my typical client does not, and my efforts at clarification are as futile as your average spec doc.

The lionshare of my client interactions are spent addressing minutiae about appearance. Despite a herculean effort at diplomacy, I still come off as an employee telling the boss that his concerns aren’t important. Call it a failure on my part, but recognize that many a layperson gets baffled by an interface simply because it isn’t pretty the way he envisions it. When that layperson is your client, work can grind to a standstill until he finally “sees” what he expects—which typically involves a LOT of detail…