12

Ask DN: PSD to HTML being dead in a large agency?

almost 6 years ago from , Interactive Art Director

One of my favorite designers/builders, Wilson Miner, coined the term ‘deciding in the browser’ (http://vimeo.com/34017777), which I have really latched onto. I see a shift happening and I think its important to monitor and think about this as makers of digital things.

Treehouse made a nice blog post about this issue the other day as well: http://blog.teamtreehouse.com/psd-to-html-is-dead#comment-37818

While I very much believe in this concept of, deciding in the browser and not replicating PSDs for the sake of replicating PSDs. My question is:

How can this concept take root in a large agency or company? This concept is great for nimble small shops, but how can it really grab hold in a larger, more corporate environment? What does everyone think about that?

22 comments

  • Murat MutluMurat Mutlu, almost 6 years ago

    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.

    7 points
    • Jonathan YapJonathan Yap, almost 6 years ago

      I work in the place you used to worked in and I can agree to this. ;)

      Clients are still used to the approach of seeing high-fidelity designs and signing them off before any development can begin. A couple of last minute overhauls on design decisions will wreck havoc when do designs in the browser. It shouldn't happen but it does unfortunately.

      1 point
      • Matthew SaforrianMatthew Saforrian, almost 6 years ago

        It shouldn't happen but it does unfortunately.

        I'm increasingly of the mind that it should happen unless the agency and company are proverbially in bed with each other. As a consultant we are most often far removed from users and the needs of a business.

        Without a deep understand it can be difficult to be agile and decisions must be vetted through those who are closer to the users. If you squint you can see Conway's Law in motion.

        If anything should change it should be the fundamental relationship of agencies and clients. If you have ideas of how to do that—I'm all ears.

        1 point
  • mewo a, almost 6 years ago

    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.

    3 points
  • Dirk HCM van BoxtelDirk HCM van Boxtel, almost 6 years ago

    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.

    2 points
  • Jonathon YuleJonathon Yule, almost 6 years ago

    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.

    0 points
  • Kenneth OrmandyKenneth Ormandy, almost 6 years ago

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

    0 points
  • Ryan Hicks, almost 6 years ago (edited almost 6 years ago )

    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.

    0 points
  • Kyle CaseKyle Case, almost 6 years ago

    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...

    0 points
    • John LockeJohn Locke, almost 6 years ago

      The larger the organization, the more siloed and specialized the job responsibilities are going to be.

      0 points
  • Trevor GerzenTrevor Gerzen, almost 6 years ago

    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.

    0 points
  • Sanchit Gupta, almost 6 years ago

    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.

    0 points
    • John LockeJohn Locke, almost 6 years ago

      That seems really odd. That agencies would agree to do design, but not the development.

      0 points
      • Aaron Lee, almost 6 years ago (edited almost 6 years ago )

        Larger companies sometimes have in-house development teams that know their system better than the agency. It eliminates a large learning curve. I don't know why you'd see it as an issue for an agency to do the design and not the development. At the end of the day, they are still getting paid for their services.

        0 points
        • John LockeJohn Locke, almost 6 years ago

          Hi Aaron: Sorry if I wasn't clear enough in my thought. I'm sure there are many agencies that do strictly design work and are happy to do so. The larger the agency, the more billable hours have to come in each month. I also know there are agencies that would only agree to do the design if the development is part of the package.

          I do see your point about in-house-development teams for companies only needing design. I suppose that also seems odd to me,,,that they would have in-house development but no one on staff to do design.

          0 points
          • Aaron Lee, almost 6 years ago

            Ah, I see your point. I think it also depends on how you price your services. Some charge based on value of the work and not by time. In this scenario it could make sense to take on a smaller project if the return is worth it.

            There are some designers in these larger companies, myself being one of them. It is a fairly rare occurrence in my opinion.

            0 points
            • John LockeJohn Locke, almost 6 years ago

              Hi Aaron: I think value basesd pricing is always the way to go. That way both sides feel like the pricing is fair.

              0 points
          • Sanchit Gupta, almost 6 years ago

            Some companies didn't value design in past. Their designs were done by Business Analyst and Developers. They had to hire developers to develop applications. Thats why they had developers and no designers.

            0 points
      • alec salec s, almost 6 years ago

        Not really. Most companies that are of decent size have some sort of dedicated technical team. Whether it's one person, or a slew of developers, the company typically likes to absorb that expense instead of contracting it out. Additionally, they (as an organization) don't typically see things in the same lens that a developer or a designer would. So, to them, it seems like an obvious call.

        0 points
  • Ryan GloverRyan Glover, almost 6 years ago

    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.

    0 points
  • Carlos MañasCarlos Mañas, almost 6 years ago

    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.

    0 points
  • Account deleted almost 6 years ago

    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.

    0 points