Design on a Deadline

Lea Alcantara

When creating or revamping your own company site, speed is crucial because it isn't a billable project. Any work you log outside of billable hours must be efficient to be financially sound. And even if you don't have an immovable deadline, there is also the reality of needing your site up and working for you ASAP.

That doesn't mean cutting corners. Your website is a critical investment. But it does mean prioritizing what's most important and adjusting your design process to suit. In our experience — both internally and for our clients — the discovery process is where we invest significant time so that the rest of the project can proceed more efficiently.

Always Be Prepared ...

For example, extremely thorough discovery can really smooth out the actual visual design process for a website. In fact, when Emily Lewis Design became Bright Umbrella, our site design phase was the fastest of the entire rebrand. We finalized the direction in two weeks, and all comps (desktop and mobile) were completed within four weeks. And that was all while managing our client projects and the podcast.

How did we do it? Lots and lots of preparation (AKA discovery):

… and Flexible

All this "heavy lifting" before the site design began meant that I didn't have the dreaded "blank Photoshop document" most designers fear and often face when starting a project. We had ironed out most concerns and communicated the most difficult aspects of our entire rebrand ahead of time, so I was able to design the site relatively efficiently.

However, it is also interesting to note that the process I followed for our site is not, necessarily, reflective of what we do for all projects. Just like the ever-changing web, our processes are flexible, which also contributed to our speedy site design phase. We adjust for what works in the moment given priorities, deadlines and resources.

And what worked for me at the moment was Photoshop.

Tools for Efficiency

With our site design, speed was crucial and we had a deadline we couldn't push. It wasn't time for me to experiment with cool new tools such as Sketch or Macaw (even though Emily and I knew we had to create an excellent mobile experience). What made sense for our deadline (and our bottom line) was to use the software I've worked with for almost 20 years: Photoshop.

With the main design tool decided, the next step was to create some easy guidelines and boundaries. I like using the Photoshop template from 960.gs simply because someone has already gone through the trouble of creating perfectly-spaced columns and gutters. And while our screen resolutions are definitely getting larger and wider, it wasn't that much effort to increase the canvas width to accommodate more room.

What to Design First?

At this point, a designer needs to make several decisions:

  • Design the mobile comp first (and/or "device agnostic" and/or in the browser etc.)
  • Design the desktop comp first (AKA "traditional" web design)
  • Once screen size is decided, determine which page to design first:
    • Homepage (a common approach)
    • Important interior page (based on the fact that site visitors are more likely to spend time or even find you first on an interior page)

I've done all of the above for various reasons and for various clients and for various projects. I could wax poetic about ideal process — device agnostic design systems completely created and executed in browser while accommodating the most important interior page — but reality is never ideal:

  • Designing "mobile-first" may not make sense (for launch, at least) if the majority of your users will view your site on desktop. Given time constraints, the additional development and testing for a responsive experience may make mobile design comps a lower priority.
  • Designing completely in-browser can stem creativity by imposing too many constraints too early in the process. I'm designing based on what I think is possible to execute and executing it immediately, versus prioritizing what is actually better for the brand then making the code work. While others may find the in-browser design process quick, it's important to be mindful that speed benefits aren't at the expense of quality.
  • While we can say there is no device — just percentage and proportions of content — we aren't dealing with hard-and-fast rules for every screen experience. For example, a typical 1.4x line-height on a desktop could look strange when the typeface is smaller on mobile. In the end, you still need the time to test (and tweak) on a few devices!
  • Interior page and homepage design starting points can be personal preference in terms of prioritizing the content. If the site is a news organization, it may make more sense to tackle an article page design first. But for a design and development agency, we point and promote our main page URL a lot.

All of this is really just a long way of saying that I decided to design the homepage desktop experience first for Bright Umbrella.

Fast-Paced Collaboration

Much like our logo design process, I didn't want to spend too much time on one design idea and wanted feedback fast. I designed three variations of the same comp in two days and sent them to Emily for review right away. We had a conversation regarding what worked and what didn't, and I sent her more refined design directions — that included the smallest screen size variation — within a week:

Initial Design Comps
Emily's initial sketches and my initial comps helped inform the final design in a short amount of time

Two days after, and a couple tweaks later, we had our final design direction for the homepage and it was on to the next pages, which, in order of completion/priority were:

  1. Work landing
  2. About landing
  3. Individual case study
  4. Individual bio
  5. Blog entry (see? I focused on the entry before the landing or archive for this section)
  6. Blog landing (which informed Blog archive, which ended up being designed in-browser)
  7. Mobile navigation
Mobile Nav Variations


We played around with various mobile navigation styles. Leftmost includes 4 blocks that would slide down when the menu button was clicked. The last 3 were tweaks of what we eventually decided (far right).

Always Time for a Consistency Check

With finalized comps, Emily could have started coding right away. But, forgetting to check for consistency can actually waste (a lot of) time. So, I took the time to review the comps holistically. Did they match? Did they make sense as a whole system? Did the typographic choices I made earlier in case study pages make sense in the blog entry page, and vice versa? Were my whitespace considerations consistent?

After I reviewed, I next cleaned up the comps, being mindful to not obsess about pixel perfection. Consistency is important, but the final product has to be in the browser, where Emily would standardize anyway. Obsessing at how perfect my Photoshop comps are just adds unnecessary time. One unit off in a comp isn't as important as units being off in the browser.

Static & Dynamic

With comps complete, it was time for handoff to Emily. But our design process did not (and should not) end in Photoshop. The static comps were just the foundation from which Emily not only developed, but continued to design within the browser. By relying on a combination of static comps and dynamic in-browser design, we were able to keep the visual design process focused and supportive of the front-end dev process (in fact, I'll be speaking about Bright Umbrella's mix of static and dynamic design deliverables at ConvergeSE).

Stay tuned for Emily's article on the front-end dev for this site (and my summary and slide deck from ConvergeSE). Subscribe to our feed to get notified as soon as new articles post!

Subscribe to the Forecast

Resources for smart business and smart websites

Ready to See Results?

We've got some bright ideas — let's talk!