Why we skip Photoshop(37signals.com)
37signals.com
Why we skip Photoshop
http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop
30 comments
Because it's the wrong tool.
http://labs.adobe.com/technologies/fireworkscs4/
http://labs.adobe.com/technologies/fireworkscs4/
Neat. I didn't know about this. Is it cool? I'm going to try the beta right now.
It's very cool, but is in danger of being killed since Adobe bought Macromedia as there's now overlap between FW and Illustrator. And Adobe is generally pretty evil.
Let's hope they keep it around.
Let's hope they keep it around.
Adobe had image-ready to compete with fireworks. Upon acquiring the Macromedia products, they canceled the image-ready line. Illustrator is a vector editing/illustration suite. Fireworks is a web graphics suite. No need to worry, there is no major overlap (or at least not enough to warrant canceling a popular software title).
Horrible advice from a company who has never lost their ass on a project when the client didn't like their HTML/CSS 'mockup'.
For a small project I spend 4-5 hours in Adobe Fireworks, then upon approval (hint: very important if your client doesn't worship you like 37signals) I build the pages out in real HTML/CSS/JS etc.
My sketch/mockup step is digital, I don't use dead trees.
Alaskamiller is right on, Photoshop is the wrong tool for the job.
For a small project I spend 4-5 hours in Adobe Fireworks, then upon approval (hint: very important if your client doesn't worship you like 37signals) I build the pages out in real HTML/CSS/JS etc.
My sketch/mockup step is digital, I don't use dead trees.
Alaskamiller is right on, Photoshop is the wrong tool for the job.
I hear what you're saying with regard to clients, but I think you totally missed 37s' point. They're NOT saying "don't mockup at all". Rather, they are encouraging an interactive process with real and usable output that adapts more easily to collaboration and change. There is nothing you can do with Photoshop that you can't do with paper prototypes and follow-on HTML mockups.
I'd take that even further and say that instead of nothing, there's too much you can do with Photoshop that you can't with paper prototypes and HTML mockups.
The ability to do drop shadows on text and use all sorts of fonts and apply a motion blur and lens flare and opacity and all that doesn't translate well to the Web.
It's very frustrating as a Web developer to have someone send an over-Photoshopped mockup that won't work well as a functioning website.
The ability to do drop shadows on text and use all sorts of fonts and apply a motion blur and lens flare and opacity and all that doesn't translate well to the Web.
It's very frustrating as a Web developer to have someone send an over-Photoshopped mockup that won't work well as a functioning website.
Clients suck, film at 11.
They code HTML by hand because it's part of creating a domain language for the application - the interface drives the data model.
They code HTML by hand because it's part of creating a domain language for the application - the interface drives the data model.
It seems like your saying it takes you longer to do it in HTML/CSS than in Fireworks. They're saying that for them, like myself, that's not the case and thus you should skip the extra step or learn to do mockup html/css faster that you can justify skipping PS.
> Horrible advice from a company who has never lost their ass on a project when the client didn't like their HTML/CSS 'mockup'.
Maybe what you should take away from this is that it's better to do your own thing, rather than be a slave to clients.
Maybe what you should take away from this is that it's better to do your own thing, rather than be a slave to clients.
>Maybe what you should take away from this is that it's better to do your own thing, rather than be a slave to clients.
What the..? Do your own thing instead of listening to your clients huh? Sounds like bread winning advice!
Sarcasm aside, I agree to a certain degree with the parent post - We do work for individual clients and design selection is their choice, since, drumroll, thats what they are paying us for! You can definitely help them out with suggestions, but ultimately your job is to make the client happy - If you are running your own company (or consulting) servicing clients, I'd say that is doing your own thing.
What the..? Do your own thing instead of listening to your clients huh? Sounds like bread winning advice!
Sarcasm aside, I agree to a certain degree with the parent post - We do work for individual clients and design selection is their choice, since, drumroll, thats what they are paying us for! You can definitely help them out with suggestions, but ultimately your job is to make the client happy - If you are running your own company (or consulting) servicing clients, I'd say that is doing your own thing.
> What the..? Do your own thing instead of listening to your clients huh? Sounds like bread winning advice!
Clients != Customers, which was precisely my point. Clients and consulting is a linear growth curve, and difficult to grow into much of a business: add more clients and you have to add more people to do work for them. Customers and products (ala 37signals) means a hyper-linear growth curve, and a nice business.
A "startup" as most people mean it here is not a consulting shop. Clearly, if you are a consulting shop, you need to listen to your clients.
Clients != Customers, which was precisely my point. Clients and consulting is a linear growth curve, and difficult to grow into much of a business: add more clients and you have to add more people to do work for them. Customers and products (ala 37signals) means a hyper-linear growth curve, and a nice business.
A "startup" as most people mean it here is not a consulting shop. Clearly, if you are a consulting shop, you need to listen to your clients.
I don't necessarily agree / disagree however there is a whole lot more to learn from Philipp Lenssen's interview of Kevin Fox than this post from 37signals about iterative design / usability
http://blogoscoped.com/archive/2008-06-02-n56.html
http://blogoscoped.com/archive/2008-06-02-n56.html
The reasoning behind the separation in these steps is for 2 reasons:
To save time on both halves. That is, the designer is designing his/her piece without worry of the difficulty, and the programmer is designing the framework without worry of user intuitiveness and style.
It so often occurs that the designer and the programmer have slightly different ways of thinking. Each party has separate concerns for the final product, and each half should be individually thinking about the future of their work and how each can be maintained.
This article may certainly apply to, and almost addresses, a programmer without a sense of concern for the user's experience and general usability.
As a front-end designer, I need the mockup process for my own sake even more than for the sake of the final product. Personally speaking, if I were to attempt complex mockups without first laying out a grid and carefully choosing my color palette, I would quickly be overcome with the duties of writing the code, and the hundreds of short-term problem solving that would arrive. My passion is never to become a flawless programmer, but it is to flawlessly design an intuitive interface. When I am creating a mockup in photoshop, what I'm doing in my head is pretending. I imagine over and over again that I am a first time user to the site, and maybe even to the internet. This duty is daunting enough without having concern over how I will make it work.
Again, this article may whisper sweet nothings to a programmer on a tight schedule, but I can guarantee you that the time to simply layout a grid and pretend will save you the time it takes to just load the monster application. And I don't know about you, but I cannot imagine a site's usability on a simple piece of paper.
To save time on both halves. That is, the designer is designing his/her piece without worry of the difficulty, and the programmer is designing the framework without worry of user intuitiveness and style.
It so often occurs that the designer and the programmer have slightly different ways of thinking. Each party has separate concerns for the final product, and each half should be individually thinking about the future of their work and how each can be maintained.
This article may certainly apply to, and almost addresses, a programmer without a sense of concern for the user's experience and general usability.
As a front-end designer, I need the mockup process for my own sake even more than for the sake of the final product. Personally speaking, if I were to attempt complex mockups without first laying out a grid and carefully choosing my color palette, I would quickly be overcome with the duties of writing the code, and the hundreds of short-term problem solving that would arrive. My passion is never to become a flawless programmer, but it is to flawlessly design an intuitive interface. When I am creating a mockup in photoshop, what I'm doing in my head is pretending. I imagine over and over again that I am a first time user to the site, and maybe even to the internet. This duty is daunting enough without having concern over how I will make it work.
Again, this article may whisper sweet nothings to a programmer on a tight schedule, but I can guarantee you that the time to simply layout a grid and pretend will save you the time it takes to just load the monster application. And I don't know about you, but I cannot imagine a site's usability on a simple piece of paper.
I think his comments are aimed at developers who do a lot of design, not designers who do some development.
For a developer, making a HTML/CSS mockup is the same kind of pretending that you're talking about. They think in HTML/CSS terms natively. It requires extra thought for them to do a mock-up in Photoshop.
For a developer, making a HTML/CSS mockup is the same kind of pretending that you're talking about. They think in HTML/CSS terms natively. It requires extra thought for them to do a mock-up in Photoshop.
This article struck a nerve for me (in a good way). It's not just that Photoshop is the wrong tool for the job, it's also that it encourages a mentality in the designer which I think is totally at odds with a positive and productive user experience. In my experience, designers spend a lot of time in photoshop making designs that "look pretty" rather than actually useful and useable. Photoshop also completely fails if you do embrace a more iterative design process, where a lot of the design decisions and even feature ideas come from creating a working product or model and actually using it.
I do appreciate those who brought up Fireworks because in all honesty I had never heard of it. AT LEAST that encourages designers to embrace the native aspects of the web interface and thus to design more closely to the medium.
I don't know if my comments really add any value here, but I just had to get it off my chest. THANK GOD people are talking about this stuff though, because I really feel like web design is going to be stuck in 2002 until people move away from Photoshop.
I do appreciate those who brought up Fireworks because in all honesty I had never heard of it. AT LEAST that encourages designers to embrace the native aspects of the web interface and thus to design more closely to the medium.
I don't know if my comments really add any value here, but I just had to get it off my chest. THANK GOD people are talking about this stuff though, because I really feel like web design is going to be stuck in 2002 until people move away from Photoshop.
There was a recent post on HN about Apple requiring designers to do pixel-perfect mockups before they got approval to move forward.
I am guessing the right solution is somewhere in the middle.
I am guessing the right solution is somewhere in the middle.
I think you have to , have a sketching/mockup process ... before you start coding html/css
- If you like to sketch on paper, or do super quick mockups in photoshop it doesn't matter. The point is don't waste too much time making it perfect just to look at it.
- If you like to sketch on paper, or do super quick mockups in photoshop it doesn't matter. The point is don't waste too much time making it perfect just to look at it.
[deleted]
Why can't html/css be your sketching/mockup process?
Because your brain works differently during both activities.
I think it would be like coding without writing down a little bit of a flow chart at least... make a minimum of a wire frame for the site before trying to code it - usually helps in making basic designs, logo placement, content placement - and navigation placement...etc
I actually disagree with this. I typically use Illustrator to mock things up before going into CSS /HTML.
The reason I do this is that when I’m in CSS /HTML mode, I feel like I’m more limited in what I can actually design. When I’m in Illustrator, I have the freedom to explore different design elements that I might have overlooked in CSS . I’ve solved many hard design issues in Illustrator that would have taken me many back and forth tweaks in HTML and CSS .
The one thing I agree on is that Photoshop is a bit awkward for mockups. I only go into Photoshop before rendering design elements into pixels.
The reason I do this is that when I’m in CSS /HTML mode, I feel like I’m more limited in what I can actually design. When I’m in Illustrator, I have the freedom to explore different design elements that I might have overlooked in CSS . I’ve solved many hard design issues in Illustrator that would have taken me many back and forth tweaks in HTML and CSS .
The one thing I agree on is that Photoshop is a bit awkward for mockups. I only go into Photoshop before rendering design elements into pixels.
I think that there is a big difference between designing a web site for an eventual user (37signals or startups) and designing a users web site (average web consulting). 37signals isn't so constrained by what end users want, and their end users generally have a better feel for how the technology actually works. The Photoshop or Fireworks step of the process is definitely important when dealing with users who are picky about looks and will make you redesign the HTML/CSS/JS over very minute details.
One of my future startup ideas is a digital whiteboard, similar to dabbleboard.com (featured here recently) that would allow you to do a quick web ui design sketch and output the html/css (or, as long as I'm dreaming, haml/sass) for further development.
I enjoy using photoshop, it allows for you to easily switch up designs, a lot faster than handcoding. Plus if you using it with ImageReady to slice and dice it into HTML. You can't beat it for quick prototyping
I have found that when I do sites for myself, usually use this approach and minimize the initial design in Photoshop. For clients I try be "professional" and use the paper-psmockup-apporove-code flow.
wow... lot of anger both ways.
All I know is a as a designer at a startup I almost never use photoshop. I use a pen and then I do mockups in HTML, CSS, and javascript. It's definitely the fastest way for web applications.
All I know is a as a designer at a startup I almost never use photoshop. I use a pen and then I do mockups in HTML, CSS, and javascript. It's definitely the fastest way for web applications.
Why I skip 37signals: because all those guys seem to know how to do is play contrarian.
The takeaway should be, "get to a functional prototype ASAP and don't sweat pixel level perfection if you use it", but eschewing Photoshop is not always the right path for design iteration.
The question designers should ask is "what is the most productive way to iterate/experiment with this design?" Oftentimes, it's in code. Sometimes it's in Photoshop. Hell, sometimes I take a screenshot of a working app and fiddle with it in Photoshop.
And statements like, "Photoshop gives you too many tools to focus on the details. When you use Photoshop you can’t help but pay attention to the details." piss me off about as much as statements from their previous posts like, "People who are workaholics are likely to attempt to fix problems by throwing sheer hours at the problem."
Just because people CAN do something (focus on details or work inefficiently because they are throwing hours at the problem) don't mean that the DO.