All the screens. All the time.

Here at Edgar Allan, making good products and telling great stories is our business. And responsive web design is a powerful tool we use to help our clients share all the awesome things they do — from supporting young scholars to building a better mattress. The only problem is this: The design process, which focuses on creating a series of PDFs or static images, has remained mostly unchanged since the birth of the web. The web however has changed a lot.

Designing in the browser

Widescreen. Desktop. Tablet. Mobile. Today, every site is really four sites, design-wise. But on the business-grade level (that is, for companies that need something outside the capabilities of out-of-the-box consumer site makers like SquareSpace or Wix), the fundamentals of producing and delivering design have retained the philosophy in place when there was just one screen to worry about.

In essence, we’re still designing for responsive environments…in software made for print

Think of it like designing a clothing line using only80s-era fashion plates instead of fitting live models or creating wearable samples.

Ideally, designers aim to provide a consistent experience for users, whether they are viewing a website on a large display or a tiny mobile device. The current process compels them to focus on optimizing the large and small viewpoints while leveraging technology to adapt for screen sizes in between. And, to be honest, a lot of times, the result ain’t pretty.

In addition, an industry-wide shift toward agile methodology is influencing development and management teams to re-vamp existing processes to get products to market faster.

Design teams need to do more with less time within a structure that is shifting all the time.

So what’s the solution?
Prototypes Instead of Presentations

We considered several processes to help our team work faster, produce more, and ultimately improve the quality of our work.

Option 1. Have designers learn to code so they could eventually produce designs in the browser.

Option 2. Make developers experts on type, color, and grid.

Option 3.  Look for anew toolset and reimagine the entire design process.

We figured the first two might be difficult to scale and would take too long. So, we decided to go all-in with a new approach: design in the browser.

Over the past four years, Edgar Allan has worked to create a process that would scale for design teams, provide the detail needed for developers, and meet the velocity needs for Agile focused groups.

Here’s how it works:

1. Identify the client’s needs and consider design requirements

2. Create the atomic-level elements: type, color, and photography

3. Use Webflow to create a working prototype in the browser. Doing this also creates a dynamic style guide.  

4. And that’s kind of it. At this point, we can hand a client a working prototype of their site to swipe and click around in.Something that’s much more “real” than a PDF they have to imagine interacting with.

How does design in the browser benefit our team and our clients?

·     It creates a working model that we can share with a client sooner

·     It helps the client understand user impacts on a prototype

·     It allows us to make changes before the integration phase

·     It builds a prototype that is clickable and testable on multiple viewpoints

·     Content can be collaboratively managed and updated in the browser

·     Reduces timeline and budget for the project

What great is, we’re already seeing improvements in speed to market, agility, and quality. Now we can go from a creative brief to rendering in the browser in a matter of weeks instead of months.

Want to see how this could work for your business or product? Get in touch.