In the past few years there’s been much talk around “designing in the browser” and Lean UX. Amidst all that talk, many tech companies have failed to embrace and implement this modern product development workflow. Today I’m going to talk about the realities of designing in the browser (DIB).
What is DIB, exactly?
For starters, let’s define what designing in the browser really means. Instead of trying to coin a proper definition, I’ll give a quick summary:
Designing in the browser is the process of creating and managing your user experiences in native web code – HTML, CSS and JavaScript – instead of using traditional methods like wire-framing and mockups.
Traditional Agile Development
Before we talk about DIB let’s talk about traditional agile development approaches. For those of you who are new to this, most tech products [and websites] follow a product development workflow. This is the process of creating a sequence of experiences for users to accomplish tasks (i.e. sending an email using Gmail’s interface or signing up for a new account on a website). Traditional methods of creating these user experiences involve the following process:
1) Product Requirements
Product owners start the process by defining the product requirements (ex: a user sign-up flow).
2) UX Design
UX designers turn those requirements into flat, 2-dimensional assets – most commonly referred to as “wireframes.” These assets are typically created using design software like Adobe Fireworks, Balsamiq, Azure, Invision, etc.
3) Visual Design
The wireframes are then handed off to visual designers for a more polished aesthetic – applying color, typography, imagery, etc. Again, this is commonly done using software like Adobe Photoshop or Illustrator.
4) Front-end
Once the visual design is approved by product, these assets (wireframes) are then handed off to front-end engineers for implementation. The engineers create interactive web experiences in HTML, CSS and JavaScript.
5) Back-end / Data
Once the front-end code is solidified, or even close to production ready, the back-end engineers come in and hook up the functionality to make the UX work from start to finish. Note: this phase may occur earlier in the process if you have data requirements and other non-UX related dependencies.
As the product evolves the cycle repeats – product requirements –> wireframe design –> visual design –> front-end code —> back-end Code – until a polished product becomes ready for production use.
Great, so what’s the problem?
The problem with this approach is that it’s slow.
You can imagine the time expense when changes need to occur (ex: a new requirement comes into play). Now we have to go back to UX design and work our way through the sequential steps updating all the assets. This “assembly line” workflow is extremely expensive, especially for young startups where time is critical.
Another problem [around time] is the team’s ability to get ahead and work pro-actively instead or waiting around and working reactively. For example, it can take weeks or months for the UX design and visual design to take place. During this time, front and back-end engineers often have no visibility into the product, preventing them from seeing and raising concerns or questions with the product. On the contrary, if you do include engineers in the early UX/design stages you’re taking them away from what they do best – code. So the time cost is unavoidable when you invest in the traditional approach.
How DIB Works
Now that we’ve covered the traditional approach and it’s problems, let’s talk about designing in the browser and its more efficient process. There are many variations to the DIB process, and each team can find a pace and process that works best for them. For the sake of this article I’m going to explain our process at RxREVU (a healthcare tech startup) as it relates to the way we operate.
1) Product Requirements
Like the traditional approach, we start with defining what we’re going to build and why. However, everyone on our product development team (product owners, designers, and engineers) is included in the initial conversation. We call this initial conversation a “project kick-off” meeting, where we describe the high level requirements and address the problems they intend to solve. Basically, what we’re building and why.
2) DIB Prototyping
Once the product requirements are established and broken out into Pivotal Tracker stories, we start the DIB prototyping. The key here is prototyping – which does mean not polished interfaces. We need just enough visual representation to talk about the experience and understand how it works (ex: page flow, dropdown menus, modals, web forms, etc.). You can think of it as 75% complete UI. Our UI engineer (which happens to be me!) quickly creates web pages/views using HTML, CSS, and JavaScript.
The intent of this step is to give the product team everything they need from a UX perspective so that we can make decisions and move forward. For example, if we don’t like asking users to sign up via modal we’ll create a new standalone page. This type of decision making can be done extremely fast using the DIB process – no reworking of wireframes, mockups, etc. Just a few modifications in a few lines of code.
3) Back-end / Data
Once the team feels good about the prototypes we get our back-end engineers in to start hooking up data and functionality. This allows the entire team to see the product come to life before any final visual design is addressed.
Some may argue that this could have a negative impact on process… for example, why would you want engineers building things that haven’t been 100% thought out? On the contrary, we find it very helpful. It provides an opportunity for us to see and address problems early on, as opposed to later in the process when design is already finished. Instead of having our UX/design dictate code, we allow the two to grow simultaneously so that UX and engineering can be mutually inclusive and compliment each other.
4) Visual Design
As our engineers wrap up the logic and data, our UX engineers start to apply the final touches that refine the experience and prepare the product for production. This is followed by some QA and then we deploy!
So, as you can imagine, this process is much faster than the traditional approach. This is true agile development – being able to quickly build, refine, and repeat.
Major Benefits of DIB
- Faster Product Development – reduce the time and expense of the traditional “assembly line” workflow
- Optimized Velocity – empower your team to work more efficiently with less “down-time” and tighter integration
- Better Context – see your UX take shape early on within real context (inside your apps!)
- Centralized Information – keep all your design and code in one place
Okay, sounds nice. Now how can my team do this?
Good news – if you’re team is relatively small there’s no reason you can’t start doing this immediately. Just share this article with the rest of your development team and discuss a variation of the DIB process that works for you. In fact, you don’t even have to completely switch over… perhaps try it out on a smaller product feature that you’re planning to deploy. If it results in a smoother, faster workflow you’ll have a foundation to scale from.
For larger teams, this could take more time and experimentation. Moving away from the traditional approach, that most larger teams use, requires more than a small change in process. It requires a change in the way they operate, the way they hire, and the way they allocate time.
Regardless, here are some other tips to help you embrace the DIB workflow:
1) Hire front-end engineers that can design AND code.
Your front-end engineers should be able to design UX and code front-end (HTML/CSS/JavaScript). This is the new standard. People who claim to understand user experience should also know how to create these experiences. The days of static, flat files are over… for smart teams at least.
2) Get your entire product team thinking about UX.
By this I mean EVERYONE should be thinking about UX. Sure, front-end folks will have more experience and impact, but back-end folks should understand UX as well. If everyone is on board to create the best user experiences you’ll start cranking on a whole new level.
3) Stop using static design assets!
As I said before, the days of static design files are over. They don’t truly represent UX. Assumptions have to be made, interactions have to be explained, and they’re a nightmare to manage. Your users are going to use live, interactive experiences, so you should start in that medium.
Summary
Well, for those of you who read through this, thank you! I hope it was beneficial, or at least interesting on some level. I’d love to hear any thoughts, comments, and even critiques in the comments below!
Ali Jafarian
Ali is a father, husband and serial entrepreneur with a deep drive to create. He writes, records, codes and builds things to inspire the artist in all of us.
Discussion