almost 9 years ago from Wes Oudshoorn, Co-founder at AppSignal
I was wondering how many of you design in the browser? This could be your full workflow, but also a part of the workflow.
For those who do not design in the browser, what is keeping you from doing it?
For those who do design in the browser, What do you like about it, what do you hate about it? What tools do you use? What's the golden tip to do it right?
On the web and in apps where interaction is design, and prototyping is the design process, designing in the browser is the only way to go. In other words, in the world of apps (web and mobile) Photoshop is about branding, not so much about design.
That's why I go from rough paper sketches straight to the browser.
Some have said the browser approach is limiting or that it makes you "think in boxes." One could easily say the inverse: you can't design for interaction or make apps in a static medium. Interaction is present when designing in the browser, and gives you a fuller picture of your project.
In the context of designing static websites and that kind of thing Photoshop seems to work fine for many people, but when we're talking about apps I'm curious why people even bother?
Another reason I design in the browser is that I never really learned to use Photoshop and Illustrator - I learned design in the browser by looking at the source code for websites I liked and tinkering with them. Similarly, working in the browser also makes you a much better coder, just as sketching a lot makes you a better sketcher.
I tried to upvote this twice.
ditto :)
Partly.
We build prototypes of bits and pieces but to be honest, I've found the whole jumping from sketchy paper layouts straight to HTML to be inefficient for us and the types of clients we often work with.
I get the whole MVP/Prototypes are the best thing for UI testing etc but I keep finding project after project that clients simply don't get it and the part where historically we would have sent a photoshop visual being removed causes them some anxiety because they don't have the ability to piece together a style/pattern library themselves (even when it's presented, they often need to communicate it to other members of their team).
The main problem for us tends to stem from there being a bit too big of a jump from initial sketches to wireframe style prototypes and then the application of their brand and style guide late in the process. They don't have a true feel for what their site might look like until quite late on.
I've tried this approach with a few clients in the last couple of years and to be honest, I'm going to back to providing a reasonable fidelity visual of a key page/pages of a site to help reassure. The caveat of course is that the visual is at a particular size and doesn't allow for the many variations in display but it will show a little more "complete" picture to a less technically/design minded client (typically that board member who is never in a meeting but swoops in at the last minute with feature demands).
It's not an ideal process but I feel providing a bit of a snapshot of a page with some branding applied and perhaps a feel for content would look like closer to completion helps build confidence at an early stage more than some sketchy HTML and it's a damn site quicker to communicate.
I'd still then jump to HTML at a reasonably early stage in a project but feel there's a decent case (for the type of projects and clients we work with at least) for not binning a decent quality visual at the moment.
I'm not sure I understand. Why would your HTML/CSS designs be any different (or as you say: less complete) than your Photoshop exports?
I found it quite interesting that you were talking about the certainty your client needs about knowing what the end result will be. This is a big issue why people like "finished" designs early on in the process.
I heard people say: "Showing your client a Photoshop mockup is the best way of showing them something their website will never look like." I hope we find ways of giving our clients certainty without showing them final designs in photoshop.
Thanks for sharing your thoughts :)
You don't need to give them absolute certainty. Just confidence.
I've heard all the quotes about how Photoshop isn't like "the responsive web" etc and I've happily drunk the KoolAid as much as the next man trying to find a good balance between code prototypes (costly in initial time to code relative to a rough visual), hard to ammend without lashing more HTML and CSS at something and quite often once a prototype has been through several rounds of feedback and tweaks, the code is so hacked up it needs rewriting anyway.
I've tried combining that approach with style guides which is a reasonable halfway house to establish a look and feel but again, if a client doesn't "get it" and can't piece together a style guide mentally then I no longer feel its worth my time to force the issue when I can give them a rough representation of their website.
In the many years of doing design work I've happily tried a lot of stuff and my earlier comment feels about right for my current projects and our clients and works for us.
As ever, your mileage may vary and depending on which person is flavour of the month on twitter or speaking at a conference you'll probably end up hearing some sort of absolute statement about how X is wrong, do Y or something like that!
As in really designing (coding) in the browser?
data:text/html, <html contenteditable>
(paste that string into your browser's address bar; code to your heart's content)
Thanks for sharing! I am probably missing something here, but how do you add any css styles?
You could add css styles from the web developer (right clock, inspect element).
Above is a neat trick, easy for finalising copy with clients next to you, but an editor with live reload does the trick as well.
Completely in the browser.
Now that isn't to say that I don't fire up Photoshop or Sketch during a project, but the lion's share of the designing that I do is in code. This allows me to see a realtime preview of how things are going to look. And it also brings to my attention things that may be too complicated to work the way that I expect them too.
For communicating visual design to the client, if I'm not showing them a full HTML comp, then I'm talking them through a style tile that shows the elements of their site. Depending on the sophistication of the client the style tile can be as simple as a few colors and fonts or as complicated as a home page mockup at a default size.
I like how you say "depending on the sophistication of the client, ...". It is so important to work on this as a designer, knowing your client and adjusting to his / her level.
Tried it, but for me it's much too limiting, because it always takes a certain amount of time until you marked-up something in the browser. However in a graphic app it's much faster to test out ideas, to try new things. Also, if you design in the browser, there is a much higher risk that you just think in boxes. Sketch is still the tool no. 1 for me to design - sometimes I also iterate on things in the browser, but mostly I jump between Sketch and Chrome if I design stuff.
Knowing what you use a tool for is quite good. What I like about working in HTML first is that it really makes you think about the structure of your page. This is often so much more important than that "creativity".
The tools we use steer our design direction. Design in the browser does this, but Sketch / Photoshop as well.
I work in a team setting that where clients expect a process or method. We've tried a handful of things but end up showing them something visual before we present code. Usually we get buy-in then we move to the browser where design and developer works together. A lot of times I will work in the inspector to make adjustments and just screen grab and tell dev's 'make it look like this.'
Clients still need photoshop mockups to feel secure and some devs don't have a strong enough design eye so they also benefit from the mockups as well. I feel that some sort of mockup is important to make everyone feel secure. Once you do that and build trust you can zero in on features to make them better using a hybrid of code and mockups. Just don't let people look at the mockup as the end all be all. Open collaboration and understanding is key.
Pretty much how i operate.
Yes I do, straight from paper to the browser
Yes, I built Grunt based Starter kit for myself to allow building in Sass with Live-Reload for multiple devices.
http://vaibhavkanwal.github.io/PrototypingOnSteroids/
This has helped me move away from Codekit and share this with people and team mates without worrying about the platform.
I've built something similar as a starterkit. One thing that you do that I'm going to steal is loading variables with data.json. Love it!
Thank you for this, I just had the thought of configuring something this the other day!
Yes, always if it's a web app/site. I go straight from paper sketches to code. For many reasons:
I don't do wireframes. I find them pointless and disruptive. If the client insists on wireframes it's time for a discussion about why we need wireframes, and if yes = figure out if the value of a wireframe is justified by the (often large) extra cost.
I do basically the same thing in Photoshop/Sketch that I do in code, so no reason repeating myself. It actually takes longer for me in most cases to do the same thing in Photoshop/Sketch as I do in browser.
The limitations of Photoshop/Sketch...when I design in-browser I can immediately check different resolutions, and I'm not guessing at what would work, or how I would implement. Also, repeating elements isn't really great in PS/S.
When the design is done, it's ready for approval and subsequently handover to the devs. There is no implementation phase - it was baked into the design phase.
Some clients annoyingly want to sit next to you for some parts of the design phase, and I find the 'quick fix in the inspector' route to be way quicker than juggling tools in PS/S to try the things the client wants.
Being able to cut time (cost) for the client by skipping one step is a good way of selling your services.
For me, the way to look at it isn't that PS/S is one thing and the code is another. They are both tools to achieve the same goal. But by using PS/S you are adding an unnecessary step to the process.
I only design in the browser.
I love it for two reasons
1) Changes are fast. If you have to add another item to a navigation, that's one line of html <li><a href="">my item</a></li> but in Photoshop it's resizing every nav item and moving everything around and then doing that for all the other breakpoints.
2) I work in news and a lot of what we do is time sensitive so sometimes we have to take a lot of shortcuts.
Tools
We use Middleman for one-off apps and we have a lot of middleman templates that generate most of the background code we need.
I also have a bunch of grunt tasks and templates that help me quickly spin up projects.
Also, our Media Stack, Chorus, has a SASS tool built in with articles.
Tips
I totally agree.
With every site I build, I'm constantly adding reusable chunks to my personal code library. It was hard at first, but once you've iterated a bunch, and you know and have trust in your own library - building is FAST.
I'm keeping a list of notes with each project, to document where I'm getting tripped up and how to improve for next time. That iterative process is so important.
As someone said above, clients do have a hard time understanding what's going on without PSDs - and I do agree. No client I've worked with has ever grasped the "design-in-browser" thing and that's been a bit of a burden until recently.
I designed a website for a client a week ago. I got into the browser as soon as I could - and once done - I used a screenshot extension for Safari to generate a full page image of the design. Each time the client wants a change, I'll tweak the code, and then just run the extension - linking them to the image. They also have the added benefit of seeing the live site too, but the images put them at ease.
So jealous of Chorus... great advice, important to think in patterns you can pull from and reuse: http://patternlab.io/
Usually, I just make a rough wireframe, sometimes on paper, sometimes in my head. Then I jump straight to coding.
What happens sometimes, is that the client (when I show them the html), sometimes doesn't see it the SAME way I am seeing it, or they check it on the phone, when I still didn't touch or cofigured all the media-queries. That kinda sucks.
As some people said here, sometimes the client feel better with a Photoshop-made .jpg.
Also, in my opinion, web designers tend to have a certain "style". In my case, most of the times I am doing an .html website, I use Bootstrap framework, or even Foundation sometimes. So I already start with a basis.
:)
Design wholly in the browser? Not quite.
I like to work from sketches/wires to pseudo-polished designs, and then refine, refine, refine in browser. There's a point of diminishing return to continue polishing in PS.
I do, but I don't start there. Personally, I find it quicker to sketch out ideas in Photoshop before moving into code. I find if I don't have a rough idea of the design before developing, I'll end up either writing bad code or refactoring quite a lot.
But I think it's impossible for the original design to be translated to the browser without things having to give. Requirements change, elements render differently and actual data will break your original intentions anyway.
No. But it depends on the project.
...and the team.
...and the client.
There is no binary answer for this discussion. I've found that the best answer to this debate, and many like it, is often: "It depends."
Same here. It's a balancing act, especially if the client thinks you're working "too fast" by already showing them concepts in the browser.
Depends on the project. However, mostly it is a strong yes.
Reasons
I do like it due to the fact that I am making a product in the form it is going to be used by the end audience.
Tools
I did not get along with LightTable and all that “live” (we’ll see about Firefox for Developers). For me it is still a BrowserSync and task-runner (currently is a Gulp). Mostly, the joy is with SPA apps while setting a remote REST api, so everything is super lightweight and does not decrease a battery life.
Golden Tip
The most important thing for uninterrupted process is to set everything right. I mean packages, dependencies and needed tasks for the project. After that, it is as smooth as it can be. Once you understand there is nothing except creative to do, job becomes a joy.
However, I still do recommend to lay everything in your head on the paper or in the actual Sketch.app first.
Could you share a bit more info about your Gulp workflow? I can't get BrowserSync to work with Sass & Autoprefixer.
I sometimes like to decide or make alterations in the browser based on ideas, sketches and thoughts but I would be cautious about saying I 'design' in the browser.
I think design as a term is too broad and takes in to consideration too many factors to be able to say that we actually design 100% in the browser. I feel the browser is just one more tool we can use to turn design ideas and thoughts into shippable products.
I have Jekyll to thank for my current workflow - which includes breaking everything down into maintainable chunks that I can use from project to project.
Right before I start in-browser though, I do something a bit different, I don't use Photoshop to knock out quick comps ... I use Flash CS4 - I've just always found it easy to draw on Flash's canvas - how weird is that? Once I've got a loose visual to work with, it's straight into a new Jekyll project spun with Yeoman (jekyllrb) and off I go.
Part of the work is in the browser. But not at first.
But, personally, I find it horribly restrictive and stifling to design straight in the browser. It makes me think too much about code and how I will build something vs. how it should feel.
Visuals are an important part of how something feels, just as much as how it reacts. I find it more effective to work out visual exploration first and then move into the browser to flesh out interaction and details.
I think you can try to use products like http://convertifire.com, in order to design in the browser (if you want to change specific features and elements, not creating a new page / screen), but without any code.
I like to sketch on paper first no matter what, so designing in the browser makes sense for me on most projects.
I do use the browser in my workflow. However, I use it pretty much exclusively for quickly trying out different CSS values. Although this comes at somewhat of a risk, what ends up happening is I go on a CSS-modifying spree and make a ton of changes and one of two things will happen.
A) I accidentally hit refresh - losing all my changes - and hit my head on the nearest wall
B) I change too many properties and forget what I did so I have to hunt them down and copy the changes that worked into my source
So.. yeah.. be cautious about that but I do it for minor changes or weird layout issues (or for quickly trying out new colors). But other than that I stick to other tools.
Nope. Axure is way faster.
I think you have to have some sort of visual design before getting into code otherwise you'll be wasting time. Now, the tool in which is used for that initial step is up to the creator. I usually prefer a higher fidelity so by the time i'm in code, i'm simply pasting hex values, and referencing my design for margins, padding, ect.
Always.
I was never designing for web using Photoshop or Illustrator. I did it for print only.
I'm coming from development and I feel the browser and the device. No sketching tool, perhaps, is matching this feeling.
During years I've created my own front-end and UI framework with reusable components, now using the Atomic design model and Styleguide driven design powered by Gulp, Swig and SCSS.
With this toolbelt and skipping Photoshop I usually reduce project time by half
Changes take much longer in code than in Photoshop. I've got to have a very clear idea of what I'm doing before I take it in browser.
But browser is part of the process... either working with the front-end developer or prototyping myself.
Paper -> Browser.
Sometimes I have to step into photoshop is a super hacky way to see how something would look and to save time.
Although it depends on Project, teams etc. But what I have felt that Designing in browser works well when the same person is doing is design and development. luckily I'm doing both at current so it's fine. I jump from Wireframes to Bootstrap. And I do prototyping in tools like Codepen and Jsbin, they have in-built livereload. Every-time I think i have reached at good stage. I save current milestone and start working on new fork of it. I share jsbin url within team, everyone see it on browser and it's responsive. I use http://lorempixel.com to add placeholder images to my prototypes. Subtle patterns bookmarklets to try backgrounds in design http://bradjasper.com/subtle-patterns-bookmarklet/ and css time saves like this http://enjoycss.com
I did a blogpost on this a year ago with some tips on how I do it.
https://medium.com/@assentorp/how-i-designed-a-website-without-photoshop-53e4fdd4457
Hell yes.
Sometimes I would sketch on paper, and then work directly in webflow. If there's not many images to create it works great.
Depends how much I am unsure of going in.
I designed in the browser exclusively until Sketch 3 came along. Since there is finally a tool that can help me work out visual ideas as fast or faster than coding, it's about a 50/50 split for me nowadays.
Kind of. My initial designs are made in Sketch / Illustrator but when I start building the site, the majority of the code is written in the browser and then copy/pasted into Sublime :)
It depends on the project, but it is something I like to do. For responsive web site or web apps I think it is essential to prototype in the browser to show different screen sizes. I'm not a fan of producing 4-10 individual mockups for different screens sizes when I can show that in the browser. One of the bigger benefits for client work is the client sees exactly how it looks in whatever browser they are viewing it in. So there are no surprises when it launches.
Something that is essential to this process is the inspect element tool in your browser. For often than not I am inspecting and making changes in the browser before updating my HTML + CSS.
No.
Reasons:
I'm still very basic when it comes to html/css. I understand the technologies I'm design for and know about leading tech, but I have trouble translating design into code with my head. I do some code just not very well and not very advanced with it. I use compass and sass and that's about advanced as I get I suppose.
Stakeholders/clients need buy in on the design and flow with something that represents a high fidelity visual or close to it. Which is where clickable prototypes with invision or marvel are handy for me.
I typically work with a front-end dev to help implement designs and interactions.
As James Young put it. Partly
After I have the mockups ready, I do one of two things :
If these mockups are part of an existing project, with some code already written, my next step is jumping straight to designing in browser
If these are for a new project, I go to sketch, do my thang and then move on to the browser
As for what I like about it, I would have to say the speed, cross browser testing capabilities and a ton of other things that I wont go into detail about since you have probably already seen yesterdays post : Why we skip photoshop.
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now