
The other day a friend of mine said something that caught my attention, “I’m trying to learn how to slice a PSD.” It’s a simple enough statement. As soon as he said it, I knew exactly what he was talking about, and yet, there was something in there that didn’t quite set right.
Upon seeing my hesitation my friend responded with a question, “Do we still slice PSDs?” Great question! For beginners, jargon isn’t merely jargon, it implies a process and suggests a method of action. For this reason, it’s often helpful for more advanced developers to define their terms in a way that is meaningful to others. Today we’ll dive into the theory behind the process of converting a PSD to to a web page and end with a discussion on the ups and downs of designing in the browser.
Like the article? Be sure to subscribe to our RSS feed and follow us on Twitter to stay up on recent content.
We won’t be actually converting a PSD to HTML/CSS today, we’re merely discussing the how and why so you can fully understand the typical approach taken by today’s web designers.
I needed a PSD to reference throughout the article so I grabbed the awesome free Creative Studio Minimal PSD from GraphicsFuel.com.
The first thing we should talk about is what it means to “slice” a PSD. Put loosely, the term simply means to chop up your Photoshop document into pieces, which then get served up to the web server, put in order by HTML and styled/positioned by CSS.
On a more specific level, slicing can refer to a specific set of tools inside of Photoshop. Using the Slice Tool, we can partition our document up into little pieces. Basically, we just draw a rectangle around every item that we want to separate into an individual image.

The slicing tools in Photoshop are merely there for convenience. There are a ton of great web designers today that never touch them and there’s nothing wrong with that.
The point behind the slicing tools is to make the process of saving out a bunch of images easier, both in the short run for the initial build and in the long run to make revisions. Basically, what it does is save you the trouble of cropping out each portion manually and saving it.
Though the process is kind of a pain, I have to admit that a nicely sliced PSD is a thing of beauty. Here’s a clear example where I have several elements that need to be saved out as images. Without slicing, each one of these would represent a crop and save process that I have to go through.

When they’re sliced though, a single Save For Web action can convert all of thes slices to standalone image files. This really cuts down your time on the repetitive task of cropping and saving if you’re working with a single Photoshop file as your source.

If you’re still unsure about the Photoshop slicing tools or think that it’s all a big fat waste of time, you should check out our piece titled, How to Make Slicing Suck Less: Tips and Tricks for Slicing a PSD.
In that article, I thoroughly explain the process of slicing and how all of Photoshop’s slicing tools work. Most importantly, you get a look at some great tips on how to make the process of slicing much better. Things like Layer Based Slices and hiding Auto Slices really go a long way towards making it a bearable process.
So that’s slicing. Now that you know what it’s all about, it’s time to explore how this process has changed over the years to a point where slicing is a fundamentally different activity than it used to be.
Once upon a time, no one used CSS (I know, the horror!). Even when CSS did come along, the tools that it provided web designers with were pretty limited compared to what we know today.
Consequently, websites that tried to push the limits by not looking like crap tended to use a ton of images. Every time a design contained a custom font, simple gradient, drop shadow or rounded corner, an image had to be used to pull the effect off in the browser.
Consequently, slicing was a big deal. When you created a Photoshop mockup of a website, if you decided to implement any sort of aesthetic icing, which was huge before the minimal kick we’re on now, then you had to slice every little portion of your design up into tiny pieces that you likely then used HTML tables to reconstruct. Brutal right? Especially when you consider that we were all on amazingly slow web connections back then so all those images took ages to load.
As CSS evolved and grew, a new trend popped up in web design: imageless design. If you looked around on design blogs a few years ago you would see a ton of articles titled something like, “Create a Fancy Button Without Images!” To this day you still see titles like this pop us as people perform unbelievable feats with CSS.
This trend wouldn’t be possible without the amazing CSS features that we now enjoy. Suddenly you can round corners, add shadows, implement multiple backgrounds, build gradients, use custom fonts and a lot more using pure code. The general goal of many web designers now is to leverage CSS and use as few images as possible in our markup. “Imageless” isn’t necessarily something to be achieved (you almost always need a few images) but rather strived for, meaning you generally want to get as close to it as humanly possible while keeping support high.
This trend comes with its ups and downs. The up side is that, despite what non-coders might think, CSS is a beautifully easy way to maintain and adjust a design in the long term. If you want to change something small such as a font or a background color, you just find/replace a few lines of code and you’re good to go. There’s also the benefit that even thousands of lines of CSS can be minified to the point that its effect on loading times is nearly negligible.
The huge, not to be understated downside is compatibility. With images, PNGs were pretty much the only thing we had to worry about (aside from loading times of course). Now with CSS we have support issues across the board. Browsers that do support a new feature do so only with a unique prefix, making for ridiculously repetitive coding, many features are only available on a single browser engine, others are supported everywhere but IE (some things never change); it can be a real mess.
The ultimate goal is to keep what’s best for the user in mind. If using an image for something results in the greatest amount of good for the most people, go for it.
Building on this foundation of information, we can finally address the question of whether or not web designers still slice PSDs.
For the most part, when we look at a Photoshop document that is meant to be converted to a website, we try to see code wherever possible. It’s like that moment in the Matrix where Neo looks around at what he once saw as the normal world and suddenly sees the code behind it. Web designers don’t see layers and layer effects, we see divs and CSS properties.
Given that this is the case, the majority of the work involved in taking a static design live is more in the realm of rebuilding than slicing. Instead of slicing that glossy button and serving it up as an image, I’ll use CSS to rebuilt it from scratch. This process is repeated throughout the whole of the site, often with images used primarily for actual content rather than design (though there’s still plenty you can/shouldn’t do with pure CSS).
The question that no doubt comes to the mind of many web design newbies as they read about this process is of course, “Isn’t this all a bit repetitive?” First you design and build a site in Photoshop, Illustrator, Fireworks (yes, I remember that Fireworks is great for web content so don’t yell at me in the comments) or any other layout tool of choice, then you basically start over in the browser and rebuild what you just created using code instead of images wherever possible.
The answer is a resounding “yes.” The result is a movement of folks that encourage moving the design process right to the browser. Start in code, finish in code, use Photoshop only when you need to create an image and virtually eliminate all this repetitive nonsense.
I’m all for this process. It’s super lean and really streamlines your workflow. Unfortunately, it’s not always easy to get the creative side of your brain to produce your best work utilizing this method. Sarah Parmenter recently addressed this problem in her post, “I can’t design in the browser” in which she reveals the “guilty secret” that even though Photoshop isn’t a good way to display the kind of dynamic and responsive web content that clients need today, it does foster more creativity than going straight to HTML and CSS.
This post represents a long answer to what seemed to be a simple question. However, under that question is something that we’re all struggling with lately, from beginners to professionals: What’s the best process for designing a website? Should the creative design process be distinct from the coding process or should they be one and the same? Should we build mockups in a layout application and then slice them up for the browser or is there a better way? Is Fireworks really the answer or is there still a missing solution?
I want to hear your thoughts on this. What does your current workflow look like, from beginning to end? Where do you begin the design process and how does that flow through to a live website? What tools do you find invaluable along the way? What would your ideal web design tool be like?
I basically design in the browser, especially because using responsive grids is hard to mimic in photoshop. However, when unsure about the clients expectations of the design, I sometimes make a quick impression and send that image to them. Mostly so they can tell me what they don’t like about it so that I learn what they might like (Quite a few have a hard time articulating that: ‘i like apple, i like an open airy feeling, i want it to look professional’)
Great article, I’ve always wanted to know peoples thoughts on slicing, I personally never use it and always felt I was only doing half my job as a designer…I am reassured now that I’m not the only one.
Another thing mist by many designers is dat the fact that nobody uses html anymore, we use templates for systems that generate html. These templates consist of smaller templates to generate a part of the page (menu, header, footer). What looks like several templates in photoshop is very different from what it actually ‘is’. For me photoshop just feels to static compared to what a website is. Especially since neither the site, nor the design is made using a waterfall method: feedback comes halfway through and changes the specifications and the design.
Two thoughts.
Despite it being a bit more cumbersome, I do prefer the separate file method to slicing. I also have done it this way a bit longer.
The other thing we forget, slicing is necessary for building emails. If you are hand coding the table, the slice selection tool makes quick work for getting dimensions for your cells.
I do still use slicing (in Fireworks), but like you said with the growth of CSS there is less need for so many images. In many cases with a design now days I only have a couple slices, so its no big deal. It is worth noting however I do lean a little more minimalistic with my designs..
I stopped slicing probably a few years ago. Pretty much for the reasons that you’ve described here. However, I do still design in Photoshop at the early stage of the process. I do this for the reasons Sarah mentioned in the article you linked to and because it’s easier to get some early feedback from the client this way. Before you jump into the code you can pass along a jpeg of the design and get feedback on layout, color, type, etc. A lot of these changes are easy to make in Photoshop, some will be easier to change in code.
Something not really hit on in the article is responsive and fluid design. We can’t do this in Photoshop. My solution to this is to still design for a wide screen solution in PS and get that to the client. Once approved I use this file as the base for my design. These days instead of going back to my PS file for images I find myself going back for values such as the offset and opacity of a shadow for example.
The folks at Upstatement wrote an article about their workflow for the responsive design of the Boston Globe site and I found that it echos my process in a lot of ways: http://upstatement.com/blog/2012/01/how-to-approach-a-responsive-design/
I usually will create the homepage of the site in photoshop, just to get the look and feel down. After that, it’s all in the browser. Interestingly, when I taught web design, I taught my students to slice their PSDs (but did mention that it’s not strictly speaking necessary), yet I don’t even recall the last time I sliced up a website design PSD.
When I started to design in 1999 I used slicing at every project but through the years as there was a push towards more dynamic content I moved on. Then I took a break from it all. When I came back and refreshed I realized that it was a totally new world and I have to become more agile. Today I use layout software to come up with the direction and then move to the browser. This seem to work for me!
As Joe said, the slicing technique is still useful for HTML emails.
I create sketches of the layout and a moodboard to define the overall style, but I do most of the design in the browser.
I’ve tried designing in the browser, and I don’t care for it. Probably because I was a designer first and a developer second. I can achieve the minimal look that is popular right now when designing in the browser, but for anything more detailed and visually complex, I need to use photoshop to get the creative juices flowing otherwise I find myself to constrained by the code.
I find I get the most interesting results by designing in photoshop (with wireframes and such done by hand first) with no thought to how the code will work and then challenging myself to make it all work. With this method I’m not constrain with what html and css are capable of in the creative stage of the process.
I think it’s still a good idea to allow designers to use Photoshop (or whatever preferred tool) for conceptualizing and playing with ideas, so their creativity is not constrained too much.
We tend to start with moodboards, then move to style tiles (http://badassideas.com/style-tiles-as-a-web-design-process-tool/), then to maybe two or three overall page samples, such as homepage, first-level, and second-level pages. Some sites might only need one if all the pages are similar.
But after that I think it’s best to do as much as possible in HTML/CSS/JS, with designers conceptualizing new or changed elements only (not entire pages) and providing imagery where needed. The advantages are just too many:
- can integrate content, functionality, and design early on so they all inform each other.
- designers can focus on conceptualizing and solving creative problems, rather than being a production artist for a bunch of (constantly-updated) comps
- If using a CMS, can actually allow content contributors to manage their content directly in the CMS, rather than asking developer to keep updating changed text.
- the reality of implementing in HTML sets in early. It nips in the bud problems like designs that vary too much from page to page (arbitrary changes in font size or color, etc.), designs that don’t reflect existing content (or vice versa), or client-maintained content that needs too many special classes to style.
- allows changes to make development easier to happen early, before anyone is married to the design concept; conversely, allows more time for developers to work out challenging problems where we do want to stretch the envelope.
- provides an easily-viewable example of the actual site-in-progress that everyone can see. This allows everyone to understand what still needs to be done or should be changed or added (or taken away!).
- accurately represents all functionality and dynamic behaviors, such as responsive design, rollovers/hovers, drop-downs, lightboxes/pop-ups, sliders, hide/show, etc.
- can manage scope-creep by prioritizing changes – easier to make client choose between “let’s tinker with the color or animation or whatever some more” vs “let’s get the sign-up form working properly”.
- a basic site is already built early on, so it’s easier to tell client they need to pay extra for more revisions or added features than if you haven’t started building anything.
- site is testable as you go along, so there’s plenty of time to fix things early, when they’re easier to fix
- once the rough draft is done, further development work is incremental. No more waiting until the last minute to try to develop everything in a mad rush.
I don’t slice much, a lot of CSS effects + I just move objects to new windows to get a proper transparent backing.
We’ve in the last 2 weeks introduced 2 of our designers to Fireworks which some of us are using. They’ve used Photoshop all their life, and we opened their eyes to how many times easier it is to create fast, pixel perfect designs in Fireworks. Comparibly webdesign in Photoshop is like trying to play hockey with a baguette as a stick. They LOVED it. Please take a look at it webdesigners, I’m afraid Adobe will abandon it if not more people start using it. I hear way too many people using the backwards Photoshop for web design.
I create mockups in Photoshop for the client’s approval, then move straight to the browser. My boss seemed astounded when I told him I never sliced, which made me feel like it’s something everyone did and it would make my life so much easier. But reading this made me feel like less of a freak for straight coding, and really clarified when I might want to use slices in the future.
In my opinion, using photoshop at first is a great way to start.
I like to do the wireframes in Illustrator first, and then brush up and add more design effects and styles in Photoshop. This may be a rigid process but I find it easier to conceptualize on a blank canvas on Photoshop rather than doing it straight up in the browser. However, maybe more experienced web designers may be able to do it directly because of familiarity with codings and stuff, I’m still a beginner, so I find it easier to build the look and feel of the site on another application first. It may also be because of my design background, I was trained in graphics in school and my developing skills were self-taught. I have not tried Fireworks before, but I think I may start testing it out now after reading some of the above comments!
I always design in PhotoShop first and show a compressed jpeg as the mockups.
Occasionally, I’ll use Fireworks – but I’m much more comfortable in PS.
Once I have the goodies, I tend to save just the elements I need as a PNG file, and slice that file.
(I know it’s an extra step, but I can do it so quickly, slicing a design can take me less than 10 minutes).
Everything that can be done in the browser (shadows, gradients etc) is done in the browser; and often I’ll keep all images together as sprites and let CSS do the heavy lifting.
As for IE, I don’t code for <IE8 as standard, but offer it as an additional extra in the project (with additional cost).
I do know my method is slightly different to most people's; it works great for me :-)
DM
I am slicing in Fireworks which is better and faster designing tool in my opinion.
Also I am designing in the browser.
With the evolving of the responsive design designing in the browser is great option.
Gave up on slicing YEARS ago.. and never regretted it a bit.
Webdesign is for the browser and happens in the browser.
You win a lot of time doing the stuff that matters in the browser, and build the eye-candy, tiny pixels, texturing etc.. in Photoshop. Even glows and gradients can be done better in CSS nowadays.
It’s no use being anally retentive about 1pixel in your design somewhere, if you, in some cases, need to hack your way around to cater for all (or most) browsers. Better use that time to get that pixel right in the actual site.
So my workflow consists of wireframe/prototype in browser, even some design, add eye-candy on the separate elements and export those as imgs for use in the front-end theme. (or sprites, or base64, svg..)
Let us not forget that when building web applications and worthy websites, you must also be concerned with the performance of the site ( in the google site performance sense of the word ).
Because we now need to load things faster in order to rank well in google searches, developers have really adopted the technique of create image sprites. Which is not necessarily something that is a given after slicing up (or not slicing) a PSD.
Good article. I tend to really focus really heavily on website optimization when I build my PSD’s, so I often try to only add visual elements that I know I can build out in CSS. I have been using Pictos Font and CSS gradients to practically eliminate the usual design elements that I use to slice for. This rarely limits the overall design of the site but makes it really easy to implement and a YSlow score of greater then 90 is a beautiful thing. And for all the images I do need like social sharing I load in a sprite, spritecow.com does all the work for you.
Nice informative article. I really like
I usually start with a hand-drawn draft to visualize the grid and the content, then go straight on the CSS/HTML, working with just empty boxes with different background colors, at the end I add images and text..
Is it a very weird way of doing it?
and I don’t slice the PSD..
I can imagine situations where the designer actually is someone else than the frontend developer. I’ve worked with soms designers that didn’t had a clue about html, css and the likes. And they couldn’t care less. They experienced thinking about the actual markup as a creative boundary. My personal opinion on this matter is: these designers are wrong. Design is how it works. Choosing the browser as main platform for designing is a great start for that vision, but offcourse the real design process starts way way before.
Great article, I stated reading it from one of the recent emails you had sent. I wonder do we slice these days or do we just cut little 1px width gradients and shapes to repeat using CSS.