And it hit me: we are not emergency designers.  We never have been.  We ask tough questions and spend time in discovery and research.  We dig and dig before we ever start designing.  We make recommendations.  We’re not “yes” people; we’re “why” people.  When you tell us your website needs a feature, we don’t just agree; we ask why. Then we push you (and ourselves) to dig up a better answer or provide a foundation to back up your request.

And yet, we end up “hurrying up” more often then I’d like.  We tend to take on emergency projects even though they don’t fit our general mold of process and project management.

It’s not that we can’t build a site quickly; we certainly can.  It’s more along the lines of our initial approach to a project.  Once we get to the design and development stage, we’ve already done our due diligence and the process can fly. But we like to know we got there with good reason and research.  We like to know the stakeholders are all on board with what we’re about to produce, and we like to know that every conversation that needs to be had has been had.

We’ve had a virtual onslaught of new project inquiries in the past few weeks.  And that’s a great thing, of course. We’ve been working hard on great projects and launched this gorgeously redesigned site and have been out writing, speaking and getting to know folks. Our clients give us fantastic referrals to everyone and anyone. We’re busy and loving it.

Of the new inquiries, a handful are really great, qualified, well-fitting projects for our team. Clients who want us to spend the time digging and learning and researching before we build; who want us to labor over the details and create really polished, beautiful web and mobile apps.  Who want us to thoroughly test the products before they launch.

And another handful are looking for “emergency” designers to take over a project that went south or start on something immediately that was supposed to be done last week (I need this 200 hour project launched by mid-February!).

Next time you have an emergency, open this box.

To these emergency clients, how fast we can get them a proposal reflects on how fast we can turn the project around – when in fact, the two are not at all related.  We need time to spend doing our research before creating a proposal. We need time to determine the best platform and approach and our own resource assignments.  It’s a complex matrix and it all takes time to do it well.

That said, we’ve taken on quite a few projects that weren’t going well and turned them around – but those clients recognized that the process would take both time and hard work.  They brought us realistic expectations and we turned out some awesome work.

It’s amazing when expectations meet reality, isn’t it?

I’m feeling liberated in this realization.  It’s yet another “red flag” for my arsenal of client selection tools that help us determine fit for new projects, and a step forward in solidifying our approach to design and development.

Do you find yourself providing emergency design services?  How to you react and how do those relationships turn out?

1. Document Your Code.

This is the most obvious item, and the one that nobody likes to do. It seems like a waste of time, but taking a few seconds to explicitly say what everything does will save everyone time and headaches in the long run. What seems intuitive now can take a few minutes to interpret down the road, depending on stylistic differences and familiarity with the system. Your documentation could save someone an hour or two of digging through code a few months down the line.

Being able to tell what something does, in plain english (or whatever your project’s common language), with only a glance, saves time and keeps frustration down. It’s just good business.

1.5. No, Seriously, Document Your Code.

Using TextMate? “doc[tab]” above a PHP function will add a DocBlock. There’s probably a similar shortcut for practically every IDE.

Releasing a framework or library to the public? Please, please provide docs. Even just in code. Nobody wants to dissect the whole system every time a simple task arises.

2. Use Descriptive Variable Names.

$product_discounts > $pDiscounts > $pd

It all gets compiled into a symbol table anyway. Use variable names that clearly describe their purpose and contents. This is the cheapest and most effective documentation you can do. Take a look at this:

// get the discounts for each product
foreach($product_list as $product_id) {
  $product_discounts[] = $discount_model->get_discounts_for($product_id);
}

While it may not be optimal, it still makes the point. Reads nicely, right? Now try this:

foreach($plist as $p) $pd[]=$dm->dFor($p);

Does it take less time to type? Sure.

Will it make your current and future co-developers very unhappy? Yup.

Don’t do it.

The same goes for function names. If you find yourself documenting a function with “Does what it says on the tin,” you’re doing it right (you should still document the parameter(s) and return value(s), of course).

3. Follow the Conventions of the System

This is a short one. If you’re working in an MVC environment, don’t put a few hundred lines of controller logic in the view. Don’t put model logic in the controller OR the view.

Generally if things are structured a certain way, keep them that way, unless you have a very convincing reason to do otherwise (and if you do, document it).

4. Refactor Repetitive Code

I once knew a professor who said (paraphrased) “If your function is longer than ten lines, you should split it up.” I’m not going to advocate that kind of strict line count rule, but at least follow this simple one:

If you find yourself cutting and pasting code, consider making it a function. The same goes for if a particular set of tasks can be described by a function.

Here’s an example:

$this->collection[] = $this->load->something(‘first’);
$this->collection[] = $this->load->something(‘second’);
$this->collection[] = $this->load->something(‘third’);
$this->collection[] = $this->load->something(‘fourth’);
// and so on…

Inline rewrite: 

foreach(array(‘first’,’second’,’third’,’fourth’) as $thing)
  $this->collection[] = $this->load->something($thing);

Function rewrite (generic):

// if you have access to $registry from this scope you don’t need it…
function load_things(&$registry, $thing_array) {
  foreach($thing_array as $thing)
    $registry->collection[] = $registry->load->something($thing);
}
 
load_things($this, array(‘first’,’second’,’third’,’fourth’));

Of course, if you have hundreds of items in there, you’d either have to type them all out or make some optimizations. Which leads me to…

5. Multiple Lines are OK!

Break up the following over multiple lines if your language allows it: Strings, arrays, SQL statements, and long function calls.

Take the following SQL for example: It’s pretty short now, but if there were a few more joins and constraints, it’d be a nightmare to maintain on one line.

// This is completely valid in PHP. Using {} interpolation is a personal preference.
$prefix = DB_PREFIX;
$sql = “SELECT * FROM {$prefix}things AS t
   LEFT JOIN {$prefix}other_things AS ot ON t.id = ot.id
   WHERE t.id = ‘{$this->db->escape($id)}’
   LIMIT 0, 100”;

In the case of long function calls, consider using an associative array (or dictionary) to pass in extra parameters. They have the added benefit of naming what they’re passing. Example:

do_something(“things”, 2, 455, 299, 200, 349); // no meaning without looking up docs

…versus…

do_something(“things”, array(
  ‘x_offset’ => 2,
  ‘y_offset’ => 455,
  ‘x_skew’ => 299,
  ‘y_skew’ => 200,
  ‘whatever’ => 349
)); // meaning is clear!

The more you can do to make things clear, the better. Nobody likes scrolling through a concatenated string 1000+ characters long on only one line.

6. Pick Common Conventions

Choose some well-thought-out conventions for your project(s) and have everyone stick to them. Even something as simple as standardizing tab widths and types will save some serious headaches. Take CodeIgniter’s style guide for example: Probably a bit overkill in some cases (OR versus ||, for example), but it has some great ideas, and it keeps things readable across the project.

This list is not about those obviously annoying websites. This is a list of the things that many of our clients don’t think about as annoying but that can quickly turn a happy, trusting new visit into an annoyed, frustrated departure.

1. Unexpected detours and interruptions.  You wouldn’t have very many long conversations with a friend who repeatedly cuts you off in the middle of a sentence to change direction, would you?  How about if they asked you irrelevant questions or to share personal information while you’re telling a story?  Make sure you don’t interrupt your visitors while they’re reading or learning unless it’s subtle and important.  Make sure your detours are well-labeled and interruptions kept in the sidebars or footer of an article, page or post.
2. Insulting your visitors’ intelligence.  ”Click here” in association with a huge button-shaped illustration (or, really, in association with any obviously underlined link)? Constant, lengthy explanations of even the simplest of tasks on your website is insulting and demeaning (i.e. To register for our newsletter, enter your email address and click “Submit.”).  If you have to write a full sentence to explain what a person should do next, you need to either a) redesign the page/process or b) stop insulting your visitors.   Probably both.  Pay attention to your analytics and employ mouse and eye tracking services like CrazyEgg to determine your site’s hang-ups, then fix them visually.
3. Impersonal and unfriendly language. The web is, by nature, an impersonal medium.  We sit alone while we surf, interacting with the zeroes-and-ones manipulated before us.  And the third-person, buzzword-laden marketing rhetoric of the web makes it even more inhuman.  Submit?  Seriously?  How about “Go!” or  ”Send!”?  I remember working at a pizza joint in college and they actually had a mirror next to the telephone.  We were expected to smile when we answered the phone because people can tell when someone is smiling while they speak.  Somewhere along the way, we lost that smile in our voice.  Some great startups and web companies are leading the way in using friendly language – and I’m excited to keep pushing my clients in the same direction.

I have a much longer list than this as we deal with so many projects and so many ideas, but I’d love to hear what annoys you when you’re surfing … or what you have to convince your clients is annoying.

My biggest learning this week:  Think it all the way through. Design.  Content strategy.  New opportunities.  Site structure and implementation.  Be clear about what’s next.

A few golden nuggets of the week:

• When someone approaches you with a golden opportunity, understand that in most cases, they’re expecting the same in return.  One hand washes the other, so to speak.  This can work for you or against you – but think it through from both perspectives.
• When you’re designing an interface, it’s ok to break UI rules if it works best for the user – especially when no one else is going to use it.
• If you’re going to try to do something different, to be bold, be sure to think through the entire implementation – not just the homepage.  Where do we go from here?
• We all have to make compromises and need to learn what to fight for and what to let go.  This is a hard lesson when it comes to design, but we need to remove emotion from the equation and keep it as impersonal as possible.
• Even if you think something looks awesome, if the colors remind someone of a childhood trauma, it’ll never fly.  (That’s ok.)

It was a week of big lessons – but I anticipate there being a lot more “hey here’s a cool JQuery technique I tried!” next week as I get rolling on actual design and coding again.