Thoughts on Designing in the Browser

Designing in the browser (DITB) has been something commonly talked about over the past few years. It’s often mentioned to introduce a number of benefits which, coupled with the right tools and processes, could enable designers to quickly produce functional, responsive websites. In cases where budgets and deadlines are tight, this sounds like a great route to take. But is it really that great?

DITB comes with numerous benefits. It allows for rapid prototyping, almost simultaneous usability testing, and can be supported by a vast number of libraries and frameworks that make building websites easier. Many articles out there that advocate for DITB state that the traditional “waterfall” method is too slow and too pixel perfect, making it unrealistic in an age where more Americans are relying on their smart phones and tablets for internet access. DITB is said to require a new way of thinking as it requires considering things like usability, accessibility, and content strategy while building something that works in a multitude of devices.

Putting it all together at once sounds like a great idea, right?

Personally, I don’t think it is. Coding and designing require completely different ways of thinking. Doing so introduces additional layers of obstacles that pulls designers away from focusing on a single objective and ultimately stifling creativity.

Here’s an example: Building wireframes in the browser. The purpose of wireframes is to visualize the decisions made pertaining to information architecture, content organization, and functionality. To do this, they’re created with just enough aesthetic to communicate purpose. So what happens when you decide to create wireframes in the browser? You’re adding more things to think about; writing semantic code, building grids, messing with frameworks, and so on.

Okay, so what?

We know that humans are horrible at multitasking. But an article by the Harvard Business Review states that multitasking also causes efficiency to drop as low as 40%, long-term memory suffers, and creativity is reduced. It’s not that we can’t multitask, it’s that we can’t focus completely when doing so. The reality of it is we’re either doing one or the other. Maybe even one at the cost of the other. If accessibility, usability, clean code, etc. are extremely important to us, should we really be doing things in a way that hinders our ability to do them properly?

Then how should these things be approached? How can we assess these important components and still rapidly build websites that work in a multitude of devices and browsers? Maybe we can sketch our wireframes beforehand and move to code once everyone has signed off on it. Or maybe we can work iteratively until we’ve covered all of our bases. Even better, maybe we shouldn’t try to do them all at once.

By now, you might be thinking this isn’t really about DITB and that’s basically what I want to get at.

Here’s the real truth: Designing in the browser is not the problem. It’s our design process.

From the macro perspective, designing in the browser is actually a step in the design process. It is not the opposite of the “waterfall” method. You can design in the browser and still be using the waterfall method. It’s one way of creating ideas whereas designing in Sketch or Photoshop is another and neither are the right or wrong way to do it. The design process should decide which method is appropriate for the project, the stakeholders, and the business needs. That decision is guided by the information learned in the research phase, which is dependent on the facts and questions built up in the planning and discovery phases. If either of these phases are poorly executed, you are left with a design phase full of risks and where I believe the problems associated with DITB or static mockups originate.

So what’s a good design process? There are a ton of them out there, all of which containing a different number of steps in them. Search and you will find them, all different yet applicable in their own way. Generally speaking, a good design process involves

1. establishing the project’s direction by identifying what we know, what we don’t know, developing S.M.A.R.T objectives, building requirements & constraints, understanding stakeholders and identifying everyone that needs to be involved with the project,
2. utilizing research methods to frame the problem to be solved, to understand the business and its environment, to define the users, understand who they are, their needs & frustrations, and to gain insights to help form a design solution,
3. creating a design brief, laying down design principles, sketching, creating wireframes and/or prototypes, and building them for production, and
4. implementing and validating our designs using the test metrics we established in step 1.

So if we’ve gone through the first two steps and came to the conclusion that we need to test a large number of designs to understand our users then we might want to go with Sketch & Invision. The same would hold true if we had a client from hell who was extremely sketchy or vague about their vision. This would allow us to make quick changes and export them into Invision for testing. Once we have arrived at a solid solution, the design can be translated into code with little issue. But if we had a solid solution and an established design direction, jumping straight into code wouldn’t be a bad idea. It’ll also work if we’re building a site that doesn’t require a lot of visual design. In summary, these decisions are based on what we learn in our design process, not what we think is simply the “right” way to do things.