I'm all for the approach but I've worked in several large agencies and the clients just don't go for this.

The agency will only try and push the issue so far, clients see value in what they know.

You also take away the opportunity for agencies to add billable hours for PSD design rounds.

Maybe 4/5 years time we might see the change but right now it's incredibly difficult.

Although I hear in some shops like RGA they design-in-browser but then again they have great innovative clients who listen to them.

There was a discussion on HN yesterday about this from both developers and designers. Read some of the comments from devs on what they expect from designers - it's really interesting.

https://news.ycombinator.com/item?id=7058121

I'm part of one of those nimble (3 man) shops and we do have a lot of control over how we work. We've been doing more and more work in the browser but can't completely ditch photoshop as clients have become accustomed to seeing something designed / finished before it's built. This is a bit frustrating but understandable, it will change in time.

This sounds like just another "it depends" situation.

There are so many cases you can come up with where Photoshop is just easier, and vice versa. It depends on the stage of the project, the requirements, the team you're working with, etc.

Imo, these are so intertwined that it's hard to give a clear-cut answer without going into details on a gazillion different cases.

I'd say, put it in your bag of tools and use it wherever you think it'll save you time, effort or money.

I agree with most people here that in an agency environment, this becomes difficult. What some here are forgetting is that an agency's primary goal a bulk if the time is to create a campaign... a visual and emotional experience for a brand... not just a website or app. Those are just different mediums to tell the over-arching story.

Thus, when pitching or reviewing work with clients, they are going to want to see more than just a "40%" vision of a site... they are going to want to sign off on mockups of the banners, the billboards, the website, the app, etc ... they want to see the entire vision.

Even if the agency was hired to do just the website, not doing high-fidelity mocks puts them at a severe disadvantage with the client. It opens up TOO much imagination and assumption... "trust us, this will look like blah-blah" will be imagined completely different ways by different stakeholders. Too much money is on the line.

My concern with this whole "kill PSD to HTML" movement is that a lot of the time I see details, consistency and overall polish put to the back burner. As "flat" has become popular, I feel some developers have become over-confident on their knowledge of design and sacrifice too much... especially with fonts, spacing, etc.

Overall, I keep hearing this "it's crazy to expect a front-end developer to code an entire site in HTML/CSS" attitude and it confuses me. That's what many of them were hired to do. Just because you may have more "in-browser" design "tools" available to you, doesn't make you a designer. I have a few wrenches at home... and I can change a shower head like a BAWSE.... but I sure as hell don't think of myself as a plumber by any means... I trust them implicitly when something important is on the line.

I think there are a few reasons that have made this issue so big lately, some of them being:

1. Designers that aren't designers. Too many kids skipping design school or not taking the time to properly self educate. Crappy grids, half a dozen different fonts on a page, no real understanding of code, etc. I feel this has pissed off a ton of devs... had to take matters into their own hands, etc.

2. Sprints are being taken too literally. Some companies are sacrificing detail and overall quality in order to make sure things technically reach deadlines - very short deadlines. I'm all for sprints and they work awesome when done properly, but I feel a lot of places are doing it wrong (or underestimating), thus everything is a rush. Many times devs will have to plow forward 100% off rough wires in parallel with design in order to make the deadline and you get a lot of moments where a designer will pass something off a day later and devs will be like "well, we did it this way". Again, it's less of a knock on the use of sprints... but more a knock on people running them not knowing what they are doing.

3. Developers sometimes care more about the tech behind something than the emotion/experience that the clients are really paying the money for. The clients are sold on a story, a vision... they don't care so much what acronym you used to make it work... unless it's part of the PR behind it (ie: first site to fully adopt X). For many of these people, it's like the Mercedes they bought instead of the BMW or Audi... they just care about the outward presentation. Most of them could care less about the exact tech used to make all of it work. They want it to work and they want it to look good. This is why the Phaeton failed for VW. It worked, and worked great... but it wasn't an Audi for the same money. In fact, for some things inside the car, it was superior to the Audi, but it didn't matter... it wasn't an Audi on the outside.

This is a bit unrelated, but...

I'm a "design in the browser" type of guy and over the last few days I've been working with a client that provided a design in Sketch. When the design is done correctly and matches developer expectations: having a "PSD" can be awesome.

In comparison, having a design meant I was able to make choices about code very quickly. When I do this in the browser, I usually find myself fiddling until it's just right.

Now, I'm not suggesting that things like slicing are valid. Rather, that when quality and style are of the utmost importance, having a design to base your code on is a good thing.

To loop back and answer your question, it might be wise to suggest the benefits of designing in the browser (speed, fluidity in the design) vs a static document (more time but higher quality, decisions are made if done correctly).

Ultimately, learn to do both and know when one is better than the other.

In many corporate environments it can ruffle a lot of feathers to start writing code when you're a "non-developer".

Sometimes you have to pick your battles. Design .psd or sit through a two hour meeting about roles and responsibilities...

The article on treehouse is misleading IMO. I think design in an editor (whatever it may be) is still very relevant and most likely will never die. Comment by Amy on the treehouse article says it perfectly for me. I've worked for numerous companies big, small, and true start ups that still use wireframe>high fidelty comps in PS>front-end prototypes>back-end connections. I still use it and it's still very relevant in industry to have that workflow. Of course it needs some tweaking to become more agile to fit with today's standards, but I doubt it will ever die. Frankly, I hope it doesn't.

That's why http://macaw.co/ extists, and I think is what designing will evolve more to in the web in the future.

Totally agree with this. In my experience both at big agencies, small agencies, startups, as a freelancer, and an in-house designer, not very many talented designers are talented developers, and vice versa. It’s a classic left brain / right brain scenario. Those that are truly talented at both are very rare unicorns.

This is similar to how interior designers or architects are not the construction experts building the house — they are trained in 2 different arenas. I am a trained designer (and not a developer), and I need to use photoshop to concept and plot out a good design. I try to stay aware of the different development standards, but that doesn’t make me a developer (you don’t want me building the house, but I can help make it look awesome, and I’m aware of how it’s done).

I present the high fidelity mockups to the talented developers I work with, and we see how close we can get to that design. My developer colleagues also give me input and insight about cool things that can enhance that design. And yes, sometimes I give them pixel specs as a frame of reference because we’re still in the process of phasing out pixels as a standard. From there, we go back and forth, and things naturally evolve. This has always been the case with a psd to html workflow — things just evolve in that translation from a visual blueprint to an execution on the web.

I think that as an education resource, this article runs the risk of conveying a picture that isn’t accurate — that working from a high fidelity psd design mockup inhibits the development process. With responsive being the standard now, of course there are added steps of collaboration between designers and developers, but that doesn’t throw away having a mockup to work from. Not having a solid mockup gives you no solid design foundation, and runs the risk of creating a frankenstein of a site.

There’s also the situation where you are working within an organization, and you need high fidelity mockups in order to get a project green-lighted, which is extremely common. If this article was totally accurate, design/development collaboration products like InVision wouldn’t exist (where the site’s whole business is about providing a place for people to discuss prototypes that are based on high fidelity mockups).

I think it’s important to be really careful and specific when writing for an audience that is relying on Treehouse as an education resource. It makes me question whether the leaders at Treehouse have really had that much experience outside of small, nimble startup scenarios where every team member has to wear multiple hats.

Interesting, I’ve always seen “Deciding in the browser” attributed to Dan Mall. Thanks for sharing the video.

By the pace that print designers have been able to get rid of getting or having to send QuarkExpress files I'm guessing it's going to be a solid 3-5 years before we see a real shift in larger agencies move to a completely non-PSD workflow.

As more and more people see the benefits in using more specialized tools and being able to communicate their ideas through in-browser mockups it will spread and those still stuck in Photoshop will be left behind.

I see it as something that needs to be shown off. Sometimes you can explain an idea, but sometimes you just have to tell someone to shut up, sit down, and listen. Maybe not in those exact words, but you get the idea.

I've noticed that I do a lot of talking, so much talking in fact that I'll talk myself out of ideas that I never even gave a chance to see the light of day. Of course you might throw an idea out that is totally crap and not pull on that thread, but what I'm talking about is if someone inside an organization believes they have a method that works better, they should get a chance to show how. If it doesn't fit, bag it.

Every organization has to find out how the individuals work best and how those individuals can combine to create the super awesome MEGAZORD.

I'm at a place where I tell people how I work, find out how they work, and say lets find out how we can work best together. If it doesn't work we walk away.

That being said I know a lot of people are in positions where they aren't the ones making the decision about who the client is. I think I've been pretty fortunate to work with people who would all give me the opportunity to express my thoughts, concerns, ideas, messes, etc. If your company doesn't I would say it's taken on more of the factory role and that's up to you whether that's what you really want to do or not.

A lot of clients hire agencies for design only and they do development in house or give it to someone else. In that case, you have to create PSDs.

I think we need that both the client and the agency make an extra effort to develop better workflows which fits in this new responsive world. We can not do it without the client.