James Kirkpatrick sent me some questions about designing in the browser, and design workflows in general to help with his dissertation at the University of Ulster. Here are my responses.
Question: Do you feel that designing in browser is fast becoming the standard in web design, or do you feel that there will still be a few die-hard designers that will refuse to adopt the idea?
I think it is definitely on its way to becoming the standard, especially with the improvements in the pipeline in terms of what’s possible within developer tools (source-map support for Sass, CoffeeScript and so forth). It’s not catching on as quickly as I feel it should be though (given the benefits I feel it has), and honestly I feel like that’s simply because it’s hard for people to drop the tools they know and love cold-turkey. It can take a while to adjust to new tools and workflows, and to be able to afford the time in-between where you just have to accept that you won’t be as productive as usual is a difficult thing to accept. I think what will speed up the adoption of these types of workflows is when people can gradually bring small parts of the in-browser workflow into their existing tools—things like exporting the CSS attributes from an object in a visual design tool (like you can do with Sketch) are great examples of improvements like this that will make transitioning more productive.
As I see it, the key advantages are as follows:
-
You can interact with WIP designs in the browser. You can’t interact with a photo of a website you’ve designed in Photoshop. This allows you to actually pay attention to the subtlety of interactions, transitions, and performance considerations of a design as you build it, rather than thinking of these things as an afterthought.
-
Designing in the browser forces you to think about things in a more sane order. If you start your design from a blank canvas and are immediately thinking about “pixel-perfection” level details of the first element you draw, you’ll spend much less time thinking about the higher level aspects of a design like information architecture, layout considerations, and so forth. When you start your designs in markup, you almost have to think about layout and document structure before you think about what your buttons are going to look like, and I think that results in a better end product.
-
When you design a web interface in a visual tool, you have no choice but to have an extra secondary step of taking that design and actually coding it up in HTML/CSS after it’s finished. When you factor in the amount of time it takes to complete both of these phases, I believe it actually takes a shorter amount of time to design in the browser instead, because you don’t ever have to reimplement your design—it’s already in the format it’s going to live in.
-
Similar to the above point, a problem of using a visual tool to design interfaces that live in code somewhere else is that you’re effectively maintaining two versions of the same interface, and it’s really easy for them to get out of sync with each other. Changes and bugfixes made in production code that affect your design don’t automatically get updated in the saved visual file, and any changes you subsequently make to a design in a visual tool will need to be reimplemented in code again too. This effectively doubles the amount of work required to maintain a design over a long period of time. When you design in the browser, the code is the design, so it’s simply not possible for the design to be out of sync with the implementation in any way.
-
Visual design tools don’t encourage collaboration, but code is easy to collaborate on. If your designs are all done in proprietary programs with no functionality for collaboration, then it’s unavoidably going to affect the ability of your teams to work together on designs. Code on the other hand isn’t a proprietary program. With version control tools, functionality like merging changes from multiple people working on the same set of files are literally built into the system, so if you can do your design work in code you instantly open up doors to collaboration on design to everyone in the team. This increases visibility into the design process, and encourages more discussion across disciplines within teams, which can only be a good thing.
At GitHub, we’re a product company, and don’t have “clients” in the same sense that many design studios and freelancers do. From my past personal experience as a freelancer though, I’d say that really what most clients want is to see projects become real things as fast as possible, and they don’t really mind what tools or workflow you use. I think clients are very comfortable being shown mockups of designs before the real thing exists, but a lot of the time I think that’s just because that’s how it’s worked for so long. I believe that if you could invite a client into your office, and show them working prototypes and mockups in a browser that you can interact with, they’d be more impressed and feel happier about the progress you’re making on the project than they would be if you’d shown them “pixel-perfect” photos of their website printed out on paper for them to approve. Regardless of whether you do client work or product work though, I believe that the closer you can be to the real, finished product, the better your feedback process will be.
Question: If you could also share a bit of information on getting rid of labels within the working environment, and how that helps productivity?
Each person has their own set of experience, their own areas of expertise, and their own set of things that interest them. I believe that teams should be made up of the people whose experience, expertise, and enthusiasm all intersect with the project at hand. If that means that you get three “systems engineers” working on a project and no “designers”, or three “designers” and one “database admin” and no “developers”, or even a more common mix like a “designer” and a couple of “developers”—then I think that’s fine, because when you get people (regardless of skill and job title) who are excited and care about projects enough, they’ll make the necessary things happen whether it’s within the scope of their “job title” or not. I’ve seen many companies where work is divided up neatly into silos of “design”, “development”, “operations”, and so forth, and having the project pass through each department “in order” means that people further on in the process often feel like they don’t have input into decisions that affect them. In my experience, it’s unavoidable that new information turns up at every stage of the design process, so there should be input from all teams working on a project at all stages if the project is to be a success. I don’t think that means you have to get rid of labels, I just think you need to be very aware of how divisions between different teams of your company are affecting your workflow and the way decisions get made within projects.
It depends on the project, but for most product and feature-driven work that I’ve done, I feel like a good balance is to keep teams small, and maybe have one or two designers working with two to three developers. Adding more people to projects often doesn’t make them happen any quicker, and I believe that reducing as much as possible the number interactions required for any given team member to be up to speed with everyone else in their team is a valuable thing to do. In larger projects where the team size will inherently grow, try and form small sub-teams with a mix of disciplines around the individual features or development efforts that need to happen, and make sure each of those sub-teams has mechanisms of staying up to date with what other sub-teams are working on within the project at large. That seems to work well for us at GitHub, but what works for us may be very different to what works at other companies and in different business models.
Question: Do you think as designers, we need to work on our work processes as a whole, to speed up our workflow?
I think as designers we don’t understand our own creative process nearly as well as we might imagine. I’ve often found that being forced to break down my thought process about a given problem and articulate the competing forces so that other people can understand the problem has got me “unstuck” in situations where just relying on my regular workflows was getting me nowhere, and I think that’s a pretty common thing in design in general, not just web/interaction design. I’m not sure speed should be the overall goal of workflows though—personally I think speed of iteration is important, but the end goal should always be to produce the highest quality software possible, and that often takes a lot longer because of the amount of thinking you have to do about your own creative process along the way.