: How do you create a client website design mockup/image? For all the graphic designers who do web design too: How do you produce client design mockups for review and then convert them into HTML/Wordpress
For all the graphic designers who do web design too: How do you produce client design mockups for review and then convert them into HTML/Wordpress etc?
Are they created in Illustrator/Photoshop and then the images extracted for use with the new site?
Can any HTML/CSS properties be extracted from a website page mockup done in Photoshop or Illustrator?
More posts by @Phylliss782
7 Comments
Sorted by latest first Latest Oldest Best
I recommend you don’t mockup the entire website at all. It only leads to misunderstanding and disappointment. Especially when creating a responsive website, which obviously is what is required today.
What I do is I start by showing the client an empty website template running on a local Web server on my MacBook, or a private staging server if I’m working with a team. I use a production-ready template and hand-coding, but you could also create a prototype in Dreamweaver or whatever you like. The client and I sit there together and we build out the template by adding the pages that we want, and adding in a little bit of content that they may already have, in some cases from a previous website.
I put a class in my template that makes elements appear to be sticky notes, and so I put any notes for each page in as divs and add that class and the fact that they are yellow blocks with drop shadows and a handwriting typeface makes it obvious to the client that those are notes, not part of their website styling. And I can set that class to hidden to hide all the notes, and we won’t accidentally deploy a note as content. The fact that the notes are overlaid on each in-progress page is much better than hiding them in a text document.
Pretty soon into this process, the client already feels like they have a new website. They can work the browser and navigate between the pages, they can see notes on those pages that say things like “headshot of John Smith goes here” and so on. The site is like unfinished furniture, but you can still sit on it and see if it is comfortable.
And since it is only running on a private server, I don’t have to worry about optimizing anything too early, I don’t have to worry about different browsers. That all comes way later.
At the end of that session, I’ll typically email them a PDF of each page of the website. I have an AppleScript that does that automatically.
Next thing you know, the client is really excited to get a new logo made, to pick a color scheme, to choose a typeface. That is when you start doing design proofs. But I don’t make them look page-y, I just do a logo card with some type under it, a nav bar, all against a color scheme. That makes it easy to do a few of them: light logo on dark, dark logo on light, maybe 3 color schemes, and I show them to the client like a home decorator would show color chits. I don’t give them a whole page to look at, just some choices of styles. It is much easier for them because they don’t have to visualize anything, and many people can’t visualize graphics. I’ve shown them on iPad or sometimes I print a few of the proofs as postcards and let the client shuffle them around and compare them. The client has a context for these design proofs because they were already hands-on with the website. Same as a home owner has already stood inside an empty white room when a decorator shows them color chits.
Typically, one of the cards excites the client more than the others and that is the one they want. No second design round. The logo of course then gets exported as SVG and we drop it into the top line of the responsive grid in the website. (I use Skeleton which is very simple and easy.) The text styles and color scheme from the design proof is — of course — put into the website’s CSS. You don’t have that step of recreating a print-style page layout because there is no print-style page layout in responsive design. You basically have one column of blocks on a phone that can expand to 2 or 3 columns (or however many you want) on a bigger screen. You don’t set text sizes based on taste, you set them based on what is readable on each device.
At this point, the client also has some more content ready — hopefully — so we load that in as well, replacing notes that are in there.
Then I sit down with the client and we go over the website again, focusing on the content, adding a few more notes, maybe an additional page.
Based on their content, I might suggest we do some animations, add some stock photos, create some call-to-action blocks for important pages (which go into the second column on larger screens and appear at the bottom of the scroll on a phone.) The design energy goes into creating/improving actual content in an actual website. We are way before launch and yet we are working the same way we might work after launch to improve the website. There isn’t much wasted energy at all. Instead of showing them mockups of imaginary website elements that they may or may not want, we look at their actual content and say: we can drive users to these 3 important pages with a set of 3 descriptive inline buttons. Or: we can do this photo gallery as a big, immersive slideshow that runs automatically and also offers forward and back buttons. Or: we should make an animation that explains this concept instead of just having a long page of text.
A key thing with this process is that you don’t overwhelm the client by asking them to visualize a bunch of stuff. You show them the in-progress page and you show them design proofs of elements and then you put that element in there and you move on to the next thing. You ask for some content or information, and you plug it into the website. You suggest a widget or animation for this spot here on this page and then you build it.
What little layout there is comes down to managing the responsive grid in such a way that your elements are appropriately sized for each other. You work mostly on the space between the elements and their relative size to each other, not laying them out within the browser window which you don’t have any idea how big it will be, or what shape it will be.
When you get the site so that it is basically ready to launch, at that point you switch to a deployment mindset and optimize, maybe move the whole thing onto a particular server and/or CMS the client wants. All the stuff that doesn’t change how it looks and feels. But you don’t waste any effort because the task is a straightforward one of improving and optimizing an existing Web document that is already full of content.
The best part is that the client feels like they were on the Web development team because they watched the site evolve from nothing. I didn’t show them a “finished” mockup that confused them into thinking the website was already built on day 1. They saw it empty, they saw it shaggy with notes on it, they saw it when the logo first went in, they saw it when the colors and type were styled. You don’t have to explain to them that a lot of work went into it, they saw that work happening in the browser view, piece by piece. When they see the deployed site they are proud of it.
In the past, I had a client express disappointment that a launched site looks just like the mockup they saw weeks before. [Sound of mind blowing.] That is a key thing: you have to understand that the client is not a graphic designer, not a Web developer, and may not even really make any kind of document regularly. You can’t necessarily show them lorem ipsum and expect them to get anything good out of that. You can’t show them a mockup that looks like an 8.5x11 page and then be surprised when they are disappointed to see just the top part of that page in a Web browser on their computer. But if you show them a raw piece of marble and say: now we are going to sculpt this into something custom for you, based on your needs and requirements — that gets them more excited than mockups with lorem ipsum in my experience.
Adobe is working on a new software for exactly this purpose. Project Comet is close to the first beta release (based on the increased amount of advertising I've seen in the last month, I'd guess the beta will start in February or March). You can sign up to get updates on the project now (see link above); from what they've shown so far, it will really streamline the mockup process.
Alternatively, check out Edge Reflow.
EDIT: Apparently, they nuked this project alongside Edge Code (not sure why though; Code had to go because it competed with Adobe Brackets, but the only Adobe-alternative to Reflow is Dreamweaver, which is a terrible program that has to die).
Can any HTML/CSS properties be extracted from a website page mockup done in Photoshop or Illustrator?
Adobe's text editor Brackets has a default plugin called PSD-Extract which you can use to generate CSS-rules from a PSD-file. It won't do all the coding work for you, but it generates relatively clean and modern code (as opposed to bad/deprecated software such as dreamweaver which will generate really obnoxious code.
There is a great and simple tool that I use all the time for design and that allows for code export as well: Webflow but if you want to use the code export feauture you need to buy a monthly/yearly subscription to do so, but its not that expencieve if you do alot of work. Oh and you can convert the code to WordPress pretty easy.
For all the graphic designers who do web design too.
Web design is a specialized branch. It is not an "aditional" one. The same as print design for flat bed press, logo design, motion graphics, etc. This basicly means you need to be... specialized.
How do you knock up client design mockups for review
My 2 cents from a previous question: How Do You Present Wireframes & Designs For Long One-Page Website?
Can any HTML/CSS properties be extracted from a website page mockup done in Photoshop or Illustrator?
Yes, some properties can be extracted from Photoshop... the bad ones. Let me explain.
Almost every program (I wonder why) tries to use the most direct method, for example using the old slices produces an arcaic code using tables, which are an interesting option for doing newsletters, but not for web design.
Or it produces "absolute position" elements, which does not apply on modern workflows for responsive design.
On a wordpress template things get more complicated than that. The code is almost usless, becouse a template need to be coded in the php files themselves.
Are they created in Illustrator/Photoshop and then the images extracted for use with the new site?
Just some elements, like logos, the correct size for cropping photos.
But a Web coder will try to optimize the resources. If you use a yellow layer as a background, it will be exported as a yellow bitmap, which is totally irrelevant when you have a css property for that.
Sketch is good for web design and can export css styles, even though photoshop is the most used program for web designs in my opinion its not the best it encourages designers to design stuff that is not possible or requires hacky css to replicate the effect.
Using sketch or illustrator limits designers to produce designs that actually support web technologies.
For a true mockups/prototypes try invisionapp. you can wireframe a website/app and attach click events where your buttons would be and take them to the prototyped page so you can show your client the ux/ user journey of the app
I'll second both previous answers, you definitely want to have a seamless transition between design and development. One option is to follow a standard 12 grid PSD template to create layout and then confirm it with a coding compliance tool like www.oss-usa.com/web-preflight?promo=web-preflight. Another option is to take something like a WordPress responsive template and use it as a layout grid in Photoshop.
You can also design / code pages from scratch using tools specifically geared for that, but that means you are not getting client's sign off on firmly defined master layouts prior to start of the project and that can get messy down the line as layout and functionality get continuously adjusted during "design".
You have two main options as workflow (although as DA01 pointed out, these are just a few of many possible ones):
Create the mockups in Photoshop or similar software, and then manually re-create them in HTML/CSS;
Create the design directly in HTML/CSS.
In option 1, you would basically use the photoshop file as a reference, mostly to calculate distances and font sizes. You can save assets to then use later (as you mentioned, images are the best example), but there would be no automation. In option 2, you would be coding your web page directly, because there's nothing better to see a website working than using the actual technology it will require.
Both approaches would benefit from having wireframes done beforehand (also as mentioned in the comments, pen and paper is usually enough!).
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.