How to deal with a small design budget

“I want my website to look like Apple.”

Ever heard a client say something like that during the early phase of a project?

What most people don’t realize is that companies like Apple employ huge design teams that work with nearly unlimited resources.

I spent several years working on those kinds of teams, never having to worry too much about budget. Now I work solely with progressive non-profit organizations that need to stick to a strict budget.

But that doesn’t mean the design has to suffer. Here are 5 things to keep in mind when you’re designing on a budget.

1. Focus on what you can do instead of what you can’t

Even if you don’t have a team of 100 designers like Facebook, or the resources to create your own custom design framework like Zurb, you can still have amazing, creative ideas.

When time or budget is limited, I start out by clearly defining my limitations. And then I think critically about how I can creatively work around those limitations. Most of the time I’m able to create a solution that’s more innovative and useful than if I’d been given free reign.

No matter your budget, focus on these things:

• User needs
• Good typography and color palettes

And you’ll design a good product.

2. Don’t underestimate the implementation of your design work

As designers, we need to know how our work impacts the entire development process—not just the budget we’ve set aside for design. I used to think that a minimal visual design equalled a simple design implementation by developers.

As I got more experience, I realized that was wrong.

“As designers, we need to know how our work impacts the entire development process—not just the budget we’ve set aside for design.”

A few weeks ago, I wanted to add an expanding search box into the header of a responsive Drupal site we were creating at ThinkShout. It took me 2 minutes to design in Sketch, and maybe another 4 to find the code for the exact same interaction I wanted on CodePen.

So if it took me 6 minutes to design and find code, it must be easy for our front-end team to implement, right?

It took 1 of our front-end engineers 3 hours to theme in Drupal, largely because the expanding search interaction I wanted was so different than Drupal’s default search module.

Aside from spending years becoming an expert programmer, the best thing you can do to understand how your work impacts the rest of the development process is to be in constant communication with developers.

“The best thing you can do to understand how your work impacts the rest of the development process is to be in constant communication with developers.”

If I’m not sure about an idea or concept, I’ll ask a developer something like this: “On a scale of 1 to 10, how hard will it be to build this?”

Any higher than 5, and I change my idea.

3. Be consistent

When you’re building an app or website, inconsistency in design wastes time. Eliminate unnecessary, confusing, back-and-forth communication by making sure text headings, button styles, and image aspect ratios are all consistent throughout your design system.

For example, using several different image aspect ratios, like square for avatars, 16:9 for news stories, and maybe a 2.35:1 for very cinematic hero images might look awesome. But if your website is being built on a CMS like Drupal, someone will need to set up all those parameters in the back end—and that takes time to configure.

By simply deciding on a standard image aspect ratio of 16:9, you’ve cut the image configuration time by 2/3. And the overall design aesthetic won’t suffer a bit.

The wireframe on the left has 3 different aspect ratios for news images, and the wireframe on the right has 1 standard aspect ratio.

The best way that I’ve found to keep my work consistent: with a component-based design approach, and using Text Styles and Symbols when designing in Sketch.

4. Focus on objectives, not deliverables or tools

Design deliverables have to make both clients and developers happy. This isn’t easy—it’s a balancing act between creating enough work to properly inform the client, while also giving developers everything they need to do their jobs.

Clients would love to see every possible page and interaction mocked up in high-fidelity at every break point with multiple variations. But most developers want you to give them an HTML and Sass component style guide and call it a day.

The reality: when you’re working with a limited design budget, you have to find a way to meet them both in the middle.

For me, having a solid design process is more effective than working through a checklist of specific deliverables. While the deliverables I work on and the tools I use vary greatly depending on the client—static or HTML wireframes, design in the browser, design in Sketch, style tiles, style guides, etc.—I actually have a pretty simple process. I always start broad before working down to the details. Style tiles before high-fidelity mockups. Sketching before coding up prototypes. Horse before the cart, and plenty of feedback in between.

With this kind of design process, independent from tools or deliverables, I can quickly and effectively adapt to any budget. How we think is more important than the tools we use to create.

5. Communicate early and often

Bad communication can be like a wrecking ball to your budget. On every project I’ve worked on, communication has been the deciding factor of success or failure.

It’s also been the main reason why a project comes in under or over budget.

So why does bad communication cost us?

Simple: assumptions cost money. Some examples of assumptions:

• Something’s technically easy to implement when it’s actually not
• The client wants 1 thing when they really want something else
• You can come back later and fix or tweak a feature

Part of a good design process involves removing assumptions. When we assume instead of communicate, problems snowball. A little assumption in the beginning of the project can lead to big delays or hot fixes once we’re knee-deep in development. And as we all know, it’s much easier to change a wireframe than it is to change a feature in a deployed feature on a live website.

A typical web design project usually looks like the graphic below. Strategy, UX and visual design, and development all happen in large blocks of time, one after another. And in between these phases exist massive walls over which deliverables are thrown to the next person or group without much of an attempt at collaboration.

Besides being a bad environment for creating a great product, this can be a mega budget-killer.

The biggest problem with this kind of work environment is that it allows no room for us to iterate and solve problems as they arise. When we’re dealing with really complex content-managed websites, getting clarity can take weeks or months.

No matter how thorough we are with our UX and design, there’s always something that comes up in the development phase that needs our attention. Sometimes clients need change. Sometimes we just didn’t consider something, or we were just plain wrong.

A better process: remove those walls we talked about earlier. If we rearrange our timeline so that design, strategy, and development happen somewhat simultaneously, and everyone communicates with each other along the way, there’s far less room for assumptions and miscommunications to rear their ugly heads.

Maybe you can’t completely change your company’s process, but you can at least start planning to save some of your design hours for the development and implementation phase of the project. Don’t be afraid to ask for clarity. Move your desk to sit next to an engineer if you have to.

“Every artist confronts a series of issues that are constraints. Those constraints are then turned by the artist into a positive force…”
–Frank Gehry

Working backwards from a budget doesn’t mean you can’t create something great. Use constraints as a challenge to be more creative, and focus on delivering the core goals as elegantly as possible.

Header image by Ryan Harvey. Creative Commons Attribution-ShareAlike 2.0.