You’re reading Signal vs. Noise, a publication about the web by 37signals since 1999.

37signals

Why we skip Photoshop

Jason Fried wrote this on Jun 03 2008 / 205 comments

When designing a UI we usually go right from a quick paper sketch to HTML/CSS. We skip the static Photoshop mockup.

Here are a few reasons why we skip photoshop:

  1. You can’t click a Photoshop mockup. This is probably the number one reason we skip static mockups. They aren’t real. Paper isn’t real either, but paper doesn’t have that expectation. A Photoshop mockup is on your screen. If it’s on your screen it should work. You can’t pull down menus in a Photoshop mockup, you can’t enter text into a field in a Photoshop mockup, you can’t click a link in a Photoshop mockup. HTML/CSS, on the other hand, is the real experience.
  2. 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. The alignment, the specific colors, the exact shapes, the little details that may matter eventually but they certainly don’t matter now. The start is about the substance, not about the details. Details are for later.
  3. The text in Photoshop is not the text on the web. Once you’re looking at a static Photoshop mockup you can’t quickly change the text without going back into Photoshop, changing the text, saving the file, exporting it as a gif/png/jpg, etc. You can’t post it online and tell someone to “reload in 5 seconds” like you can when you quickly edit HTML. You have to say “Give me a few minutes…”. Also, type in Photoshop never seems to be the right size as type in HTML. It just never seems to feel the same. It doesn’t wrap the same, it doesn’t space out the same.
  4. Photoshop puts the focus on production, not productivity. Photoshop is about building something to look at, but about building something you can use. When you’re just worried about how it’s going to look, you spend too much time on production value. HTML/CSS lets you be productive. You’re constantly moving forward towards something more and more real with every change.
  5. Photoshop is repeating yourself. Ok, so you’ve spent 3 days on a mockup in Photoshop. Now what? Now I have to make it all over again in HTML/CSS. Wasted time. Just build it in HTML/CSS and spend that extra time iterating, not rebuilding. If you’re not fast enough in HTML/CSS, then spend the time learning how to create in HTML/CSS faster. It’s time well spent.
  6. Photoshop isn’t collaboration friendly. I sorta touched on this before, but let me hit this point again: HTML/CSS lets you make a change, save, and reload. That’s our collaboration flow. “Here, let me change this. Reload.” These changes take seconds. “Here, let me float this left instead of right. Reload.” Seconds. No selecting a tool, changing a few items around manually, saving, exporting, uploading, giving people the new file name, etc. HTML/CSS is build for rapid iterative prototyping while Photoshop… isn’t.
  7. Photoshop is awkward. You can’t help but know your way around Photoshop after working in it for 10 years, but I still find it awkward to get simple things done. Working with a pen feels so much more natural to me than going back to the toolbar over and over. A pen can draw anything, but in Photoshop you need to use the text tool to type, the shape tool to draw a shape, the menu bar to adjust this or that, etc.

None of this is to say we think Photoshop is bad or a waste of money or time, but for us we’ve found that going straight into HTML/CSS affords us the best iterative and creative experience. HTML/CSS is real in a way Photoshop will never be.

Jason Fried wrote this on Jun 03 2008 There are 205 comments.

GeeIWonder 03 Jun 08

Couldn’t agree more, especially the repeated stuff and the ‘details’ points. The great thing about using e.g. a sharpie on a small pad is you can layout the important stuff without spending too much time on the stuff that matters less and is quick to change with CSS anyways. Photoshop also tends to lead to a lack of negative space, in my experience anyways.

Quick question re:”The text on the web” (sorry if this is off-topic)—is the way some of your fonts (e.g. the SvN ones) look in Opera a conscious design decision?

Robert Gaal 03 Jun 08

So I just wonder, how do you create little graphical elements like shades or rounded corners? In paint? ;)

John 03 Jun 08

I skip the paper sketch and go straight to Photoshop. It’s much better suited to the task at hand in my opinion. I do, however, treat the Photoshop mockup as a sketch and do not expect the final outcome to resemble it in any meaningful way.

Walker Hamilton 03 Jun 08

do not expect the final outcome to resemble it in any meaningful way

Then why bother?

Henry Balanon 03 Jun 08

How do you share paper sketches with the people outside of Chicago?

Eric Epps 03 Jun 08

I totally agree—I’ve always seen this step as a waste of time; but I may be biased, too, because coding for me is much easier than using Photoshop for a web layout.

Anonymous Coward 03 Jun 08

Then why bother?

For the same reason why you’d start with pen and paper.

cubiclegrrl 03 Jun 08

I agree with you about the overwhelming nature of PhotoShop (or even Gimp). But I would offer the caveat of context. Specifically, I would never, ever show an interactive interface to a typical client. Once they have the eye- and mouse-candy to play with, clients have a dismaying tendency to assume that the mockup is the application. Storyboards with screeshots of mockups in a PDF , on the other hand, are “just mockups” in their minds.

Mind you, my clients are relatively non-technical. HTML /CSS mockups work splendidly when you’re demo’ing with people who understand how much “plumbing” is actually missing. In fact, I just whacked one out last week for an internal client who is savvy enough to roll her own CSS /HTML. But for a general audience? No way in Grethor. [shudder]

No question that PDF mockups are waaaaay more work. But you only have to have your toes curl at the customers’ “Oh, so you’re almost done!” once to learn that lesson… Now, If you’ve been through several projects with a client- enough to earn their trust in your ability to estimate project time and pitfalls -you might get away with this. But to a brand-new customer, you run a significant risk of coming off like you’re sand-bagging. And losing the job (and probably the client’s good opinion) is just not worth the time-savings, IMO .

Jeff Croft 03 Jun 08

All of these are good and valid reason why skipping Photoshop seems to work well for you guys (and it does). I can’t help but wonder, though:

1. Do you think the aesthetic you guys have developed for your products makes this no-Photoshop workflow easier for you than it might for others? This is in no way a criticism, but the reality of your design aesthetic is that it contains very little texture, very little imagery, and very little depth. In my opinion, that’s 100% appropriate for your products—but it’s not appropriate for everything. Is the no-Photoshop workflow still as effective for situations that require these elements?

Which leads me to wonder…

2. Is it possible that your no-Photoshop workflow has actually influenced your design style? I tried going Photoshop-less for a while, and what I found was that I would iavoid texture, depth, shapes that can’t be created with CSS , and imagery in order to facilitate my new workflow. Ultimately, I felt it was harming my creativity. Because CSS is more limited than Photoshop in what it can do visually, I was placing those restrictions on my designs (albeit inadvertently—of course I could have gone in to Photoshop just to create a little image here and there, but doing so seemed like a chore, and I had decided I was skipping Photoshop, so it felt counter-productive to use it, even if it really wasn’t). I guess I just wonder if your minimalist, simple, flat, aesthetic is inspired by the tools you use (or in this case, don’t use).

Ultimately, I found that for me, the best workflow was to go through the Photoshop step, but to jump out of it and into HTML /CSS as soon as possible. Once I have the basic look and feel accomplished, I start working with HTML and CSS .

But everyone is different, and the Photoshop-less workflow definitely seems to work well for you guys.

Jeremy Olson 03 Jun 08

A month or so ago I would have disagreed with you but a week ago, I tried it. I started developing a moderately complex planning app for my mom to use to plan her homeschool year. I had to get it done fast. So I did some quick planning and sketched out the various screens and now I’m building the app with Rails. I can’t believe how fast I’m going: I’m almost half way through alpha development after a week and a half. And amazingly, the interface has a beautiful simplicity, a product of my skipping the photoshop phase.

I’m not sure if I will always skip photoshop from now on–for example, projects where the interface requires a highly stylized look, but I certainly am getting a lot done a lot faster without it.

nik harron 03 Jun 08

While I agree that sketching is faster, that part of the process is one that I only use for internal presentations. I always mock up the designs in Photoshop for presentation to clients.

The reasons for this are that I’m fast at Photoshop, I can create multiple layouts from the same file, it simplifies the approval loop with clients and it gives the developers that code my designs a pixel-perfect proof to slice up.

If you have a clear understanding of the way HTML /CSS works you might be able to code the design faster, but you are assuming that the person who designs the site and the person who codes it are the same person.

I find the number one spot where delays occur in web projects is the initial creative loop with the client – getting buy in – and giving them a pixel perfect proof helps to speed up that process and avoids costly changes down the road when the website they see does not match their expectations.

It’s a lot quicker to make changes on a static layout than later on after the site has been coded in my experience, irrespective of what it says in the blog above, if you structure your Photoshop document in a non-destructive fashion using vector shapes as the basis for the layout allowing for quick colour changes.

Also, it is possible to create type in Photoshop that looks exactly like the web type by using integer pixel type sizes and turning off anti-aliasing. Of course, that’s keeping in mind that many operating systems now will anti-alias type on the fly quite well especially on LCD monitors by using sub-pixel techniques, so any differences between the Photoshop layout and the comp are minimal or non-existant.

One thing to keep in mind is that a talented coder can create a near-perfect rendering of a PSD comp, but they need the comp to slice up in the first place.

That’s my two cents’. Cheers.

Eric Epps 03 Jun 08

@cubiclegrrl

You make an excellent point, I’ve run into that problem time and again—I think I’ll switch to developing in HTML /CSS and then presenting a screenshot of the page instead of the rough page itself.

Parand 03 Jun 08

Going straight to HTML /CSS requires a level of skill that many (or is it just me?) don’t have. The amount of effort I have to put into getting CSS to display the way I’d like it to is orders of magnitude more than that of getting illustrator or Inkscape to do what I want.

At the end it’s a matter of which tool gets you visualizing your design fastest/easiest. If you get there faster with HTML /CSS then more power to you, but Photoshop/Illustrator is the right tool for many.

someone 03 Jun 08

I imagine it in my head and then go straight to HTML /CSS. Hah!

It’s still better than most enterprise IT departments, which spend months on UML diagrams, specs, and other bullshit, then database stuff, then control/web services/etc stuff, and then try to autogenerate the user interface from their data model. Magic!

Marcos Kuhns 03 Jun 08

I think OmniGraffle is an excellent medium-ground. First off, you can make the mockup clickable, which is a big plus. Also “stencils” speeds up the creation process because you can drag & drop styled elements into place. This way you can have some of the nice details to inform the final design without sacrificing much time. While it’s not a perfect solution (you still have to export unless you client has OmniGraffle too) I think it’s a wonderful tool for the job.

RS 03 Jun 08

HTML /CSS mockups work splendidly when you’re demo’ing with people who understand how much “plumbing” is actually missing.

The plumbing doesn’t have to be missing. The lag between templates and plumbing is a function of how productive your programmers are and how much work you choose to bite off at a time. The first template you create doesn’t need to include all of the features that might eventually exist at launch. Part of being a good designer is leaving yourself space to add things later, while still delivering something that looks good today.

How do you share paper sketches with the people outside of Chicago?

80% of the time paper sketches are a tool used by one designer to quickly visualize his ideas and evaluate the possibilities. The few times that we do share sketches with each other, it’s almost always in person. We have occasionally dropped sketches into Campfire, but if you’re early enough in a project to be sketching on paper, it’s worthwhile to have some face time.

cubiclegrrl 03 Jun 08

@Marcos Kuhns: Thanks for the OmniGraffle tip—I’ll check that out.

James Collins 03 Jun 08

For me, using Photoshop after a sketch is a great way to explore my concept and present proofs to clients. I’d hate to code from the outset and have sweeping changes come my way.

Micheal Morgan 03 Jun 08

Completely agree. Photoshop is terrible for mockups.

Fireworks is better suited and yields higher productivity.

I can’t image the amount of wasted code you would write without a concrete mockup. I would rather spend quality time in a graphical editor than countless hours rewriting CSS . It is very easy to get absolutely lost without a solid visual. Of course details are refined during production; though, you can create micro images to illustrate hovers, dropdowns, etc.

When working with clients a mockup is absolutely necessary.

In regards to collaboration, isn’t that what I pay you $50 a month for? :-P

George Varz 03 Jun 08

I still wonder when a web designer mentions talking about PhotoShop and quick mockups in one paragraph. This is the least productive tool for doing prototyping ever. The best is HTML /CSS and second comes Adobe’s Fireworks. Fireworks is great for text, and marvelous for quick rearangements of objects on screen – just to try how it will look the other way. Sometimes it’s quicker that changing your CSS .

Everyone – try Fireworks.

Ryan 03 Jun 08

I couldn’t agree more. I can’t get myself to go straight into Photoshop for a mockup. Each time I’ve been asked to mockup something for a customer, it has been in a browser.

Photoshop is part of my daily activity, however, but not at all for mockups. As you’ve stated, it’s wasted time completely.

cubiclegrrl 03 Jun 08

RS: Again, context is everything, IMO. My principal client used to be notorious for not wanting to see the handiwork until it was all the way out to Beta. At which point they nitpicked over the tiniest gnat's $$ details. The worst of both worlds, in other words.

Then there was the time I tried a semi-functional mockup that fell into the wrong hands while I and the person who knew it was “just a mockup” were both out of the office during the same week. I came home to a firestorm that started with someone sticking her nose into something she didn’t understand and escalating that misunderstanding all the way up to a VP.

Thankfully, I’ve since managed to train them, somewhat. Actually, for the last project, they sent me the paper mockup. But I’ve been working with them for nearly three years and they were an established client when I took over the account.

Bottom line (to my mind): The design process is entirely dependent on the temperament of the customer and the strength of your relationship with them. Possibly 37 Signals has enough of a fan-base to cherry-pick your customers. Right now I can’t claim that luxury, either at the day-job or for moonlighting.

Dan Boland 03 Jun 08

Terrific post, as it describes the way I work and why I work this way.

Also, type in Photoshop never seems to be the right size as type in HTML . It just never seems to feel the same. It doesn’t wrap the same, it doesn’t space out the same.

This is always an issue when working from someone else’s comps, because the size is usually wrong. And when a graphic designer who doesn’t work with the web lays out a design based in part by the dummy type being “that size”, it kind of throws the whole thing out of whack. Related—there aren’t many fonts to choose from for the web, yet other designers’ comps NEVER seem to use them.

John Athayde 03 Jun 08

I agree 100% on the paper first mentatlity. I do all my design work on 12” architectural trace rolls. However, I find working directly in HTML can be limiting to a fault in some cases. Sometimes it works well, but sometimes, a design idea won’t come out without figuring it out in Photoshop/Fireworks (some kind of image editor).

As far as sharing, I did work for one of the largest investment banks in the world. I sat with the client and drew it out on paper. When I was remote, I’d scan and email.

Jonathan Christopher 03 Jun 08

I’d like to echo the sentiment of Jeff Croft above. I think that method probably works very well for 37signals, but I couldn’t imagine it working out for my team. I think a key difference to keep in mind is the difference between 37signals products and web design/development for clients. The 37signals team knows when they’ve got it right, and making quick changes via markup/style may be the fastest way to get things done, but in my experience leaving out a flat comp approval stage would be quite detrimental to our process. One thing we’ve accustomed ourselves to is presenting a flat comp within a web browser by applying the proper background elements (which repeat if need be) and including the comp within that. It seems to help when clients are presented a design in a pseudo-natural environment. Either way, thanks for the insight!

bryanl 03 Jun 08

old 37 signals article

In general I don’t believe in mocking up screens with Photoshop. Your HTML /CSS screens will never look quite the same as the initial mock, so it’s easy to waste time pushing pixels that won’t even exist later.

Kris Khaira 03 Jun 08

I tried mocking up with HTML /CSS some time ago and, like Jeff Croft, eventually switched back to Photoshop. It just hampers your creativity too much. Maybe you need 2 steps – mock up once for development in HTML /CSS and then reiterate again for the frontend?

FredS 03 Jun 08

I typically lay a site out in HTML /CSS – then go into photoshop and create background images, and buttons if I need to.

That said, I’ve gotten very used to creating HTML pages out of other peoples photoshop files and I find pages created that way tend to have more interesting layouts. But I’d never suggest opening photoshop to design an app. Yikes.

Steve McDonald 03 Jun 08

I’d like to here a few comments about the following statement:

Gathering requirements is doing the same work twice. Why gather requirements if I can just mock up my assumptions in HTML /CSS?

This is the next progression in the above statement for me. The truth is that shooting from the hip on stuff ends up getting me about 10% of the way there, with the devil in the remaining 90% of details. Mind you, if you are the sponsor of your own project (or in-house project) then you will likely have less hoops to jump through in the course of your work. But in the world where people want (1) eye-candy, (2) aesthetically elegant web presentations, and (3) well-defined user experiences, I am certain you will waste time writing “HTML/CSS” again and again for picky external clients.

Here is another reality. Economies of scale. Larger businesses understand the difference between code-creative and art-creative and so hire different people to perform that work. Sadly people invest in projects because of the art-creative depiction of the works outcomes in the form of a mock-up, even if the project spends most of the budget on the code-production end of things. So, in short, graphic artists get paid less, hence it is less costly to have a GA that understands usability do a mock up based on defined requirements, rather than to let a coder churn out 33% code-complete examples on a project that might get rejected because you are still in the proposal or early stages of work.

If you live and work in a vacuum, then maybe you can choose to mock up work and invest in coding earlier on. But for many of us who have to mock-up something to simply get the job, it is far faster to use tools like PhotoShop to simluate various pages and states of a web app.

For those of you who disagree, I would love some feedback about where you are drawing your aesthetically creative UI resources? Do you create your own wholistic branding-color scheme-UI standards-feedback mechanisms from graphics pilfered off of “free web 2.0 graphic generators” sites, or when/where do you take the time to address that end of the project?

Chris Griffin 03 Jun 08

For web applications, I think this approach works initially to get something functional for testing or even beta testing for a small group. But, after all the bugs and wrinkles are pressed out, a visual design is usually in order (meaning Photoshop).

A visual design phase in our projects usually comes towards the end. We want to get the interaction/flow/interface of the web application down before we start adding the style layer, otherwise, the visual design just gets in the way.

FTR , We generally start with sketches -> wireframes -> HTML /CSS and completely skip Photoshop at the beginning, but I usually end up in Photoshop at some point.

Peter Urban 03 Jun 08

We like to do quick drafts in Illustrator and the go right to HTML /CSS. The Illustrator first approach allows us to draft out a scenario and play with it very quickly and we already get a good idea how things ‘interact’ (once you’ve got your layers set up smartly it’s easy to flip between screens and versions). The next step involves coding HTML , CSS and some JS which is slower but confirms our ideas before we polish the final screen. This works very well for us but our talents are also a little more seperated between design and coding.

Nathan Bowers 03 Jun 08

Paper prototyping is the best. In the early stage of application design you need immediacy and rapid iterations. Photoshop takes too long, you get too invested in your prototype, so you have fewer ideas.

My workflow is: paper prototype > basic structural HTML /CSS > plumbing > make everything shiny with images last.

The HTML /CSS phase is important because you can do a lot of early heavy lifting with basic typography and layout, then easily add the “sheen” later.

Paper bonus: it looks “unfinished”, but is more personal and engaging. Check out these hand drawn slides from Leah Buley of Adaptive Path.

Megan 03 Jun 08

I think the answer to this question really depends on what you’re doing. When you are creating highly interactive applictions, like 37 signals does, then it would make sense to skip the static mock-up. What you’re designing something that’s meant to be interactive then it doesn’t make sense to prototype in a static medium.

However, if you were designing something that was meant to be more of a static site then maybe it does make sense to do a graphic mock-up. (I’m not using “Photoshop” here because really any graphic design program is useful for this purpose. I personally prefer vector programs most of the time).

Like others I’ve found that working directly in HTML tends to limit my creativity. I find that it’s easier to drag boxes around in Illustrator than fussing with CSS . Faster in the initial stages. I also agree with Michael Morgan in that you could easily get totally lost without a proof. I wouldn’t know where to start half the time. There’s no vision.

Jeff Croft (above) talked about your graphic style and I think this is another thing that comes into play – if you already have a defined style that you’re working with there aren’t as many benefits in creating a graphic mock-up.

Finally, I also think that beginning designers can gain a lot from working in a graphics program rather than directly in HTML /CSS (I recently published tutorial on creating graphic mock-ups for beginners). This way they can work on developing a coherent design style without being hampered by logistics or limits in their knowledge.

Tor Løvskogen Bollingmo 03 Jun 08

This is why almost all webapps I see lack a beautiful design – it’s just CSS . Sure it’s effective, but it’s ugly like a Windows ‘95. I love details and beautiful design.

Mike 03 Jun 08

“So I just wonder, how do you create little graphical elements like shades or rounded corners?”

As a coder, I’m happy to see them go. Photoshop is a photo editing and drawing program, and I’m sorry, but a website is NOT A DRAWING .

sj 03 Jun 08

Similar to Croft, we tried doing this for a while (after reading about it here.) We ended up going back, for many of the reasons others have outlined above.

What we’ve done is create a standard PSD template that includes standard form elements (buttons, form fields, etc.), some standard grids at different sizes, examples of AJAX effects (tooltips, notifications, etc.) etc. in their own folders. It helps us get things up to speed very quickly, without sacrificing the creativity that Photoshop allows. We just save jpgs of the different states on a particular page, showing internal teams how it will work when done. This speeds everything up for us considerably…

Michael 03 Jun 08

“Also, type in Photoshop never seems to be the right size as type in HTML . It just never seems to feel the same. It doesn’t wrap the same, it doesn’t space out the same.”

AND , Photoshop defaults documents to 72dpi, so when the designer says: that type is 12 pt, it’s actually not. Nowadays most screens are 92 dpi, so Photoshop made the wrong calculation. I don’t know a lot of designers that actually understand this, let alone know to change their default document settings.

Brian Dillard 03 Jun 08

Another advantage for skipping straight to HTML /CSS: Photoshop encourages all sorts of little design details that are easy to achieve in a static bitmap but difficult to achieve and/or maintain in CSS . I’ve had tiny little design details handed to me in a PSD file that caused huge nightmares on the CSS , JavaScript or JSP front. If you work in an iterative, collaborative environment, that isn’t as much of a problem. But if you’re a UI person and work in an agency/shared-resource environment where the visual mockup if your Bible, then having that visual mockup written in the actual language of the production code helps head off these mismatches.

yohami 03 Jun 08

So thats why your designs stink! lol

It´d be a good idea to go to photoshop after the very functional CSS site is working, so it doesnt interfer with your process.

Margins, fonts, pixel perfection, adds to usability.

Andrew Vit 03 Jun 08

It’s really not as simple as this post makes it sound. The correct answer- as always -is, “it depends”. Are we talking about functional design or visual design? Yes, you can definitely sketch out a prototype in HTML /CSS very quickly, but I find that it’s very limited for graphic design without using a visual graphics tool first to arrive at a well-thought out “look”.

I also find that the steps & tools that you use in the process really define how the final product will look. If I start with HTML /CSS, I naturally tend to go with a more spare (let’s call it “modern”) look by deferring to simple background-color and border styling. Adding graphics for embellishment post-facto sounds dumb. You just can’t do without something like Photoshop (or Illustrator, or Fireworks, etc…) in order to end up with a rich and well-integrated visual appearance in the end.

Besides, I never find that my Photoshop “mockup” goes to waste: it’s the source for all of the stylesheet elements like colour schemes and background images which just get plucked and saved for web. Pencil mockups don’t know pixels, so I rarely start there because I found that those are a total throwaway, unlike digital mockups which I can (and often do) come back to—sometimes much later after launch to make changes.

Philip Zaengle 03 Jun 08

So the last 6 hours of my day are a waste? :)

Steve McDonald 03 Jun 08

Something worthy of note about UI trends:

When the web first came to be, it was about HTML , which resulted in a lot of blinking text and an assorted rainbow of colors on a single webpage. Content was not king and having a page up meant you were a geek at best or surfer riding a limited version of the web via AOL (or something.)

A few years later, the grassroots of the web passed along to business and now it is a massive advertising pool, mostly pimping products or productivity. But as technology grows, the pattern goes something like this:

1. A new technique is born and the technically proficient focus on new functionally rich features (features are the focus.) 2. Later, less technically proficient people want access to those features but the interface has to be re-addressed or “dressed” to accomodate and attract a larger audience. This is typically the first thing that changes when one web company aquires another. (usability and user experience become the focus.)

The majority of Web 2.0 is currently in stage #1 above. People want features… online features. But even Microsoft is figuring this point out and producing tools that move web “features” into a more aesthetically beautiful and usable realm (toward stage #2.) The world is moving toward stage 2: which will be web 2.0 in the form of rich internet applications that don’t all look like big plastic reflective gel-like buttons that a kid could use.

In that world, once again like stage #2 in Web 1.0, we will not differentiate between requirements about functionality and the experience around those requirements (as typically presented and designed by UX people using Mock-up tools that do not focus on the programmatic.)

Gregor 03 Jun 08

You can’t click a Photoshop mockup

Fireworks is able do add clickable areas and then export as image with HTML , looks like this. Really helps to get a fealing how to navigate trough the finished site without coding one line of HTML .

I don’t know if photoshop also has a function like that

Mat Atkinson 03 Jun 08

If you need to share design ideas (scanned sketch, PDF , PSD) you can drop them straight into ProofHQ and collaborate real time.

You can even manage multiple versions, one after the other, so can progress from sketches to Photoshop to web pages in a single series of proofs.

And we’ll have some news on Basecamp integration shortly!!

John 03 Jun 08

We use Adobe Illustrator for the initial mock-ups. However, I don’t think it’s necessary to mock-up every view in Illustrator, just the broad strokes. Once we’ve decided on a direction, we proceed directly into the css/html.

If you’re really spending three days on a photoshop mock-up, you either need training or more work.

I mean really … three days?

David 03 Jun 08

I use Illustrator for mockups. Its a step up from Paper and down in detail from something like photoshop

Wolf 03 Jun 08

Just a quick reminder, since some people don’t really get it. This is about application design.

Catoosha 03 Jun 08

I’ve been told to use Fireworks as the merge of a designery look and feel and interactive elements. I haven’t made a set of wireframes using it, yet.

In my latest, I tried to convince our client that the PSD mockups were to show just the aesthetics. The wireframes showed the functionality.

This all simple approach never seems to work though, does it? The client is having me change names of things in the wireframes, as it stands, now, that could be easily done by the developers, at the final build.

nhoj samoht 03 Jun 08

I usually scribble some notes as I think of them on scratch paper. Then hit the html and css. Couple hours later with some PHP spaghetti code I have a wor

Related searches:
photoshop design mockup something working
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.