I speak from experience when I say that designing for print media and designing for the web are two completely different experiences and skill sets. Just because a designer knows print design inside and out doesn’t necessarily mean that he knows web design just as well – and visa-versa. I personally started out in web design, then moved to print design… and it turned out that my true passion was with web design, so I moved back to the web. I wouldn’t say that I sucked at print design – I wasn’t the best either (limited resources and the fact that I worked for a very small print shop with limited design services didn’t help). For me, it just wasn’t the same; I still had the mindset of a web designer. I guess that’s why I kept a side job as a freelancer for the web at the same time. Of course, I have since moved on to the coding and technical side of website-creation.
Enough about me… Let’s talk print vs web design.
There comes the occasion when a print designer needs to design a website or a web designer might have to knock out a business card. Here are a few key differences to keep in mind if you have to make that transfer at any point in your design career:
PRINT DESIGN
WEB DESIGN
Color Space
CMYK / Process Colors
RGB
Measurement
Inches, Feet, etc
Pixels, Em
Resolution
300 PPI
Your canvas size depends on what you are designing (business card, brochure, poster, etc)
72 PPI
Over 30% of users still use 1024×768 resolution – it’s best to design within 1000px wide.
Images
Vector (cleanly resizes)
Common formats: EPS, AI, PDF, TIFF (rastor)
Rastor (fixed size)
Common Formats: JPG, GIF, PNG
Fonts
What you print is what the user will see. You have no limit, but don’t mix up too many fonts in one layout and be sure to make them legible.
Limit header and content fonts to those that are widely available across all computers. You do not want to make your user download fonts. Click here for a list of web-safe fonts.
Layout
Static. Will look the same to everyone after you print it. When designing, keep margins and bleeds in mind so that important parts of the design do not get cut off.
Interactive. The layout can differ depending on computer, operating system, browser type, browser settings, monitor…
Found this great case study as I’m researching the architecture for our latest Intranet project that will be implemented in SharePoint.
We find that a good number of Intranet sites serve up a great deal of information to their audiences. Yes, audiences need to find information quick, but just as important they need to easily understand the information structure on their first visit so when they come back their experience will be even easier.
How many times have you brought a design that you’ve poured your heart and soul into before your customer, just to get your soul a black eye? The design review meeting is where good designs can turn bad, or even worse, get stifled and never evolve into great design.
Needless to say, the skills of facilitating design review meetings are an important piece of the design process. I’ve been doing this for a long time, and I still find myself refining my style and approach. Moreover, no 2 design reviews are alike. This makes it difficult to approach the situation in a more scientific fashion.
I have 8 considerations that guide our design review meetings with customers and project teams. I use the word “considerations” because I don’t believe in hard and fast rules that will work for all instances.
1. Face-to-face or virtual meetings?
I prefer face-to-face meetings over email or online meetings. There are benefits to the latter: less arguments, ideas come individualized and not in a groupthink environment, saves travel time and is convenient. I go with in-person meetings because: it’s easier for customers to give feedback verbally, a meeting allows people to focus on the design, we can have two-way discussions so everyone has the opportunity to be heard, and it’s also a good way to continue to build a rapport with your customers. I’ve also noticed subtle differences in the way people perceive and name colors. When in-person people can point at elements and also draw ideas on paper.
2. Don’t be alone
Having someone else from your team join the review meeting can be a big help. They can take notes, keep an eye on the clock, and give another point of view. Communicating design feedback can be difficult; having another set of ears can confirm or question your interpretation of the feedback. This becomes more necessary when there are multiple people in the meeting offering feedback.
3. Be upfront with meeting goals
At the start of the meeting let everyone know the purpose of the meeting, and what you’d like to leave the meeting with. For example, the purpose can be: “to pick one design direction and gather feedback”. This way all participants know your goal and will help you achieve it. If you don’t focus your audience they won’t know how to do it on their own.
4. Be upfront with how you’ll run the meeting
Now, this is tricky. There are many different ways and styles to run the meeting. I tend to go with something like this: First, I’ll present designs and I’ll be sure to go over them quickly so we can get to discussions. I’ll ask everyone to hold feedback until I open up for discussion. I tell them to take notes so they won’t lose a thought, and tell me to “pause” if they need more time on a design. I’ll present the designs along with the logic and rationale that went into it. Everything in our designs has a purpose to it. Once I’m ready to open it up to discussion I’ll either go around the room and ask for feedback or open it up free-for-all.
5. Facilitating the feedback
I defer to the basic rule of being a gentleman, keep everyone in the room as comfortable as possible. Remember, good feedback is not always a compliment. Good feedback helps to evolve the design. Open discussions diverge and create an array of ideas, suggestions, problems, strengths, weaknesses, etc. It’s your job to let the discussion flourish, while curbing argumentative or combative behavior. At some point, it will become imperative to converge the feedback into agreeable action items. Frequently, we can’t solve an issue then and there, so we acknowledge the issue and say we’ll work it out. Basically, the feedback is needs to have some form of closure or else people will leave the meeting with a bad taste.
6. Listen and defend
Your design will face loads of criticism. Hell, that’s why your there. Make sure you listen to the feedback. Even if it’s difficult and your heart rate starts racing, make sure you listen. At the same time remember that everything in your design is purposeful. Don’t be afraid to defend your logic. Always keep the audience in mind. Ask: “how would the audience react?” Always keep the business objectives in mind. Ask: “how does this impact business objectives?” Don’t hesitate to quote industry experts. “Pinaki always says if the experience isn’t good then your brand will be hurt no matter how big your logo is.” or “Technology serves a human need and not the other way around.”
7. The logistics of presenting
We haven’t completely figured this out. When we present via projector we don’t need much prep time, but the colors never look right. I like 11×17″ paper printouts because the color come across better, we can easily write on it and turn over the designs
that are out, but that takes time, and it’s not like looking at a computer screen. Moreover, it’s not green to print out so many copies. Boards are presentable, but no one can see the details of the design from far away. I’ll stick to a mixture or printout and projector for now.
8. Present a little at a time
The more things to look at, the harder it becomes for your customers to focus and give feedback. So say you’re walking into a meeting where you want to review 3 options for a homepage, interior pages, and a PDF template. You should present and get feedback one at a time. This means that you shouldn’t present everything all together and then expect focused discussion on everything. Break it up into 3 mini-presentation and review sessions. This makes it very important to keep an eye on the clock so you get through everything.
So that’s it. I hope this helps you get your designs to good places.
The Right Temporo-Parietal Junction, a portion of your brain just above your right ear is the part of your brain that helps us to understand other peoples’ frame of mind.
As UX practicioners, designers, and every developers we are always sensing the motivations and feels of people who will be using the websites we create.
Listen to Rebecca Saxe share fascinating lab work that uncovers how the brain thinks about other peoples’ thoughts — and judges their actions.
I had a hard time watching this as I’ve drafted Delhomme as my back in a few of my leagues… I hope he bounces back…
“Hey, I know you feel like crap. I mean you’re not a very handsome guy anyways, but the performer, the quarterback? I never really liked you as a quarterback. But as a person, I love you as a person.”
Fred Beecher from Evantage Consulting blogged about something that we’ve been trying to integrate through all of our UX designs for customers.
I’ve used the phrase, “We’re way past usability, we’re headed for delightability” to say that the system that we design must and by all means be usable, but we want to take a step forward and make them delightful. (I’m tired of using the word delightful BTW :)
“Fun isn’t always the new usable. There are situations in which usability is more important than playfulness and those in which it’s the other way around. The delight that playfulness contributes to an experience depends on the context surrounding that experience.”
And he’s devised 3 hypothesis:
Usability inspires more delight than playfulness does in situations in which tasks are clearly defined and use is infrequent.
Playfulness inspires more delight than usability does in situations in which the tasks are amorphous and use is frequent Playfulness also inspires more delight when there is a clear benefit to overcoming the learning curve inherent in playful interactions
The learnability of a playful system is inversely proportional to the level of interaction at which that playfulness occurs.
We loaded up the Northwind Database on a fresh install of SQL Server Express 2008 and show you how to query it from Access 2007. Great solution once your Access Database gets too big and you need the performance provided by a robust Database server like MS SQL 2008, but don’t want to loose the ability to query and report out of Access. Send requests for screencasts to share@localwisdom.com and follow us at twitter.com/localwisdom and visit us at http://blog.localwisdom.com
Looks like the entry point of thousands of new developers that won’t need to learn another language to program for the Iphone….sounds like an LW Iphone app is now underway :)
“MonoTouch drops .NET into Apple’s walled app garden
Novell has launched a new SDK for the iPhone that will allow developers to build native iPhone applications with .NET. It uses ahead-of-time compilation to avoid Apple’s rules against embedded runtimes.
Apple’s iPhone is known for its Byzantine application approval process and somewhat insular platform. Undeterred by these challenges, Novell has succeeded in bringing Mono, its open source implementation of Microsoft’s .NET framework, to the iconic device.
Novell announced Monday the official launch of MonoTouch, a new framework that allows application developers to build native iPhone software with C# and other .NET programming languages. It is designed to conform with the requirements stipulated by Apple for App Store eligibility. This will allow .NET developers to take advantage of their existing skills and potentially reuse some of their existing code when they build software for the iPhone.”
