As the web moves in a more fluid direction with sites being accessed on a variety of screens and in a variety of situations, the job distinction between designer and developer becomes blurred. Earlier this month, I wrote an article about developing websites with a code-first mentality (rather than a Photoshop mockup), which sparked some great conversations in the comments and other channels. Some people believe that a designers’ job is just to mock up designs, and a developers’ job is to reproduce those designs in a browser as accurately as possible. It is my belief that the old-school trend of passing PSDs back and forth is outdated, and in this article I’m going to outline a workflow between a two-person team, one who is primarily a designer, and a second who is primarily a developer.

Before I get into describing the workflow, I’ll recap what I wrote in the previous article on this subject. Sites should look great whether you’re reading them on a mobile device, a tablet, a laptop, a desktop, or projected on a screen. The traditional workflow of a designer passing a Photoshop PSD to a developer to hack up doesn’t fit with the way people currently browse the internet, and it will make less and less sense as screen sizes and resolutions become more fragmented. This means that we need a new workflow, one that is more collaborative, and one that takes into account how people actually browse the web, rather than assuming everyone is on a 13”+ display and browsing full screen.

Now for the workflow. Since we’re good designers, we want to start with the purpose of the website, and make sure the design serves that purpose, so that the user interface is natural for visitors. What this usually means is sitting down, designer, developer, and whoever is in charge of the content (a client or project manager, for instance) and determining what the purpose of the website will be. If your client starts by saying “I want a parallax website with music in the background and a community forum” then it’s time to tell them to take a step back and ask why. As a quick example, lets pretend that we’re developing a website for a beer company. The purpose will be threefold:

• Inform visitors of seasonal beers.

• Direct visitors to where they can purchase the beer, on tap or bottled.

• Advertise the tour of the brewery, which is totally awesome and will make anyone a fan for life.

Now we’ve stepped away from design trends, and into the “why” of the website. Often the person closest to making the product will be most able to communicate the purpose better than anyone else, but as an experienced designer, developer, or consultant you may have some great ideas based on your past experience and your expertise. Once we’ve figured out the purpose of the site, it’s time for the designer and developer to sit down together and work out some wireframe mockups of how the site will look. If you like working with a computer interface, I recommend Balsamiq, but I usually do wireframing with a pen and paper myself, with a tiny notebook for mobile design and a larger one representing a larger screen. Designer and developer can both have a lot to contribute to this phase of the design process. You may go through many different ideas or one of those working on the wireframe might have a brilliant idea right away. This is arguably the most important step in the process, as layout design guides the user experience, and every design should be looked at with the question “does this interface serve the purposes of the design?”

This is a good time to get together with the client or project manager on the project and explain how this website layout will make them more money. Focusing the attention away from specifics of design, and instead on the general ideas behind user experience and product goals means that the discussion is less about them telling you how to do the specifics of your job, and more about using the combined knowledge of designer and developer roles and the customer to come up with the best solution. I’ve talked to many freelance designers who resent the fact that their customers will take their design and demand “revisions” that are counter to the real purpose of the website. By outlining all the design decisions before the design is actually created, the customer can feel more confident in your work. Asking what the customer thinks, or, worse, presenting two options is the opposite of a confidence-building move.

I asked [Paul Rand] if he would come up with a few options, and he said, “No, I will solve your problem for you and you will pay me. You don’t have to use the solution. If you want options go talk to other people.” - Steve Jobs on hiring Paul Rand for the NeXT brand identity

What a confident statement! You’re not Paul Rand, and you’re probably not going to be this blunt with your customer, but what better way to instill confidence in a potential customer?

Now we’re to the point where, in a traditional inefficient design process, Photoshop files get passed around between designer, developer, and customer. Assuming the customer is out of the picture now and your team is ready for action, the designer will take the lead. At this point it’s important for the developer side to sit in on this process and be involved in the entire process to understand exactly what the designer has in mind in terms of functionality and style. This collaboration is where a code-first web development mentality really shines. Now we have a design and development team that is doing the job that they do best, and working for the goals of the customer, rather than a game of telephone where everyone’s opinion gets mixed up, and nobody is living up to their potential.

The design/development team is now working side by side, and as the elements of the design get worked out and passed on to the developer, the developer is consulting the designer on specifics of the implementation. The more each side of the team knows about the others’ job, the better the collaboration. However, working side-by-side means that even a designer that doesn’t know the first thing about implementing even HTML and CSS code is right there with the developer who knows it inside and out. And the developer who doesn’t know the first thing about design can implement the site without making oversights in the design, because any questions can be answered immediately, while that element of the design is still in the designers’ head.

Once everything is complete, the client is ready to be shown a fully functional website. Your team will be able to describe the function of every piece, which will preempt most questions and concerns. Everyone will be happy with the end result, because everyone did their job. The client described their design problem, the design and development team engineered a solution, the designer designed, and the developer coded. I really believe this way is more efficient time-wise, makes clients happier, and lets you, the designer/developer, do your job with minimal interference.

Let me know what you think about this process in the comments or via email and I’ll get back to you.

In the next post, I’ll design and develop a fictional beer company website and post, step-by-step, my own process.

Thankfully, the fad of smashing all possible information “above the fold” has been on a steady decline. People don’t mind scrolling, and although, obviously, the first thing someone sees on a website is important, the term “above the fold” seemed to get stuck in the heads of a lot of people. If you’ve designed websites for clients for any length of time, there’s a good chance one of them has said this phrase to you with concern about your design.

There are an increasing number of sites using long-form pages in their designs, usually on their homepage, and many use it in a very effective way. These kinds of pages are an incredibly effective way to tell a story. Like the analogue of an actual scroll, or flipping through pages, scrolling down a web page is a very natural way to progress through a series of text and/or imagery. However, as with any design trend, the original purpose sometimes gets overlooked, and the style is applied in places that it doesn’t make sense.

There are a couple of different ways that long-form websites can be effective. The most common is used to drive a call to action, another way is just to explain some sort of idea through a narrative without any express call to action. For the first case, generally the page gives a call to action right away for those that are already sold on the idea, and then gives more detail and reasons to perform the call to action as the user scrolls down the page.

Following is a few sites that use long-form design. I tried to get a variety of good and bad, big and small companies, with different designs.

Diablo 3 game page

The goal of this page is to get the viewer to download and play the demo through the call to action button: “Play Free Now”. Underneath, it gives the option to buy the game for those who came to this page for that express purpose.

As you scroll down the page, you get videos and screenshots (far easier to get someone to check out than a heavy game demo), specifics on heroes, and then more specifics on gameplay, and finally links to more information. This follows a pretty logical pattern, and I think long-form design in this manner is a good way to sell Diablo 3. It captures the atmosphere of the game while being readable and easy to follow.

Simple homepage

A long form, story-style page is an effective way to explain a unique or innovative product or service that people aren’t familiar with. The Simple site does a very good job of explaining their service, why they’re different, and the features that they have and are coming out with. Someone with no familiarity with Simple can go to that page, find out what they’re about, and decide if it’s right for them.

“Get Ready to Leave Your Bank”. If I don’t want to leave my bank, I’ll leave the site. If I do have problems with my bank, it’s a convincing line to get me to read what they have to offer. Once I’m captured by that hook, I scroll down and get a sense what they’re about as a company. This is a great example of storytelling with a long form design because they capture the correct audience, and sell them through a convincing story.

Airbnb Jobs page

This is a poor use of long-form design. I have to imagine if you’re going specifically to the Airbnb jobs page you’re already interested in getting a job there. But the jobs section is just a list of jobs with no description past the title, and there’s not even a quick way to get there aside from scrolling to the bottom of the page or clicking through their presentation.. I don’t think it really gives any sense of the culture or what working at Airbnb is like. We get a little at the very end of the page in “Common Questions”, but I doubt many people get that far if they click one of the job postings higher up on the page. To me, this seems like a page centered around the design rather than the content.

New eBay Logo Announcement

Here is our first example without any call to action. This is purely a story to convey information for a brand. Although the background is a little bit distracting, it follows a good form. First, showing the logo, by itself, with no distractions. After that, a letter from the president, and following that even more information. I like the use of a long-form page for this kind of information because it acts as a press release, but is done in a creative way that shows of the personality of the new brand.

Grouper homepage

Grouper is a startup company, and most people going to the site likely don’t know what it’s all about; it’s certainly not an established brand. We start at the top with a quick, concise explanation and a call to action, follow that with some testimonial quotes that explain the atmosphere of the brand, and then end the page with a slightly longer explanation and a list of available cities. I think it would be useful if there was another “join” button at the bottom of the site, as well as maybe a paragraph of information somewhere on the page, but overall this is an effective use of long-form design. The design itself has a lot of personality and is overall fantastic.

And that’s all. I hope these examples give you a better idea of when long-form pages can be effective, and also that it’s not a design trend that can be smashed into any use case. Let me know if you’ve seen any other great uses of this design (or even terrible ones!), and what you think of the article in the comments below.

A user interface is the product of a design. A design is a set of decisions about a particular product. Those decisions represent the product’s goals and ambitions. - Rebekah Cox, Product Designer at Quora from “Early Quora Design Notes”

It’s no secret; the latest web design trends often find their way into a large portion of any new website that comes up. But just because “everybody’s doing it” doesn’t mean it’s the right direction for the website you’re working on, or the one your client wants. Does it make sense for every product to have a website that is just one page with just a logo, email form, and giant background image pre-launch? The problem with design trends is that they are copied beyond the case that they were originally made for, and the “goals and ambitions” of the website don’t match the design and user interface.

Take the Square website for example: Square is a young company with an innovative product, and just looking at their website tells you what their product does in an instant. I’m not going to say that Paypal ripped them off, but their website redesign is very similar, albeit a much more generic styling. Paypal is not Square, Paypal is a well-established brand, and having a similar homepage for Paypal doesn’t make sense. Although they may be trying to sell visitors on one of their new services, it’s no excuse to focus user attention on something that very few people are likely interested in. Most people are going to the Paypal website to get to their account and manage it. Even ignoring that fact, their generic call-to-action style banner is not effective. Let’s compare and contrast the messaging on those two homepages.

The imagery on the Square homepage of someone using the product is very well-composed and shot nicely, and gives a great introduction to what the product looks like and how it’s used. “Start accepting credit cards today.” is the headline. The simplest way to explain what the product does. Then the smaller text below: “Sign up and we’ll mail you a free Square Card Reader.” which is a brilliantly simple call to action. It’s impossible to go to the Square homepage and not understand what the product does.

Paypal, on the other hand, starts with an image of an iPhone, two mugs, and salt and pepper shakers, with one mug on top of a bill. Even within the context of Paypal the company, the messaging isn’t initially clear. If you notice the somewhat subtle bill under one of the mugs you may think “oh, maybe it’s two friends that went out for coffee, one payed the bill and the other one sent money with Paypal.” I’m not sure if this is the purpose of the imagery, but I doubt most people look at the picture long enough to figure it out. Next, we get to the headline: “An ATM is more convenient when it’s in your pocket.” What? I use an ATM to get cash so that I can buy things at places that don’t take a credit card; that has nothing to do with my phone or an app. Then the text beneath: “Send money to anyone from anywhere with the free PayPal mobile app.” What does this have to do with an ATM in my pocket? Is the Paypal app supposed to replace me going to an ATM to get cash?

This is a great example of one company following closely a design of another in the same industry, and completely missing the mark design-wise. Design decisions should represent the product’s goals and ambitions, rather than just be a function of design trends. Maybe your client came up to you and said “I want you to make our website look like [insert industry leader here]’s website”. Sometimes it can work out alright, because presumably these trends exist because they work for some subset of websites, but starting with the design without thinking about the focus of the website will lead you down the same road as Paypal.

Starting with the product’s goals and ambitions, whether it’s a website about a product like Square, or a website that is a product like Quora, leads to the best user experience. Copying web design trends or, worse, mimicking another site element-for-element skips the most important part of the design process. Next week I’ll take an in-depth look into the design of Quora’s news feed page, which is one of my favorite examples of a page that produces relevant content (good product focus) without unnecessary clutter, and have some innovative UX that is still intuitive and doesn’t break user expectation.

Let me know what you think in the comments or via email.

There is a revolution happening in the world of web design and development. Designing a website in a raster Photoshop file and handing it over to a person or team to “chop” it into HTML and CSS doesn’t make sense any more in a world of countless different displays and rapid iteration web development.

What kind of display are you reading this post on? A 27” 2nd display, 13” laptop display, an Android smartphone, and a retina iPad display are all vastly different mediums. In 2002, when more than half of displays were 800x600 resolution, and most of the rest were 1024x768, it made sense to design a website with 800x600 in mind. Now, however, designing a website for one resolution in Photoshop just doesn’t make sense. As retina displays (and other high pixel density displays) become more popular, it makes even less sense to start from raster-based PSDs.

The solution is to start with wireframing the UI, and then jumping straight into the code. Why create all the elements in Photoshop when many of them can be created in scalable, resizable, retina-friendly CSS? Whether you prefer pen and paper or like to use a mock-up tool such as Balsamiq, it doesn’t really matter; the idea is that you get the design and feel down in wireframe, and then go straight to coding a working website. With HTML5 and CSS3 templates and frameworks such as HTML5 Boilerplate and Twitter Bootstrap, it’s easier than ever to start building a responsive, grid-based website. This blog is currently powered by a blogging framework called Octopress that has these responsive features built in. Even though I haven’t taken the time to customize it very much yet, it looks great on any size display, from mobile devices to large external displays. I have the framework, the next step is to turn it into what I want it to look like.

A common pitfall of using these frameworks is that sites end up looking like a website based on a specific framework. Another site of mine, Fantasy SOS, is based on Twitter Bootstrap. It’s not the prettiest thing ever, and it is obvious that it’s a Bootstrap site, but it took less than an hour to customize it and give it a distinct personality. A couple more hours and I can make it look like it never was a Bootstrap site to begin with. This trap can easily be avoided by wireframing your site first, and fitting the framework into your idea, rather than having the framework shape your site.

Another huge advantage of designing within a working website is that it makes rapid development much easier. Instead of going back to Photoshop whenever you want to change the color or size of a button, it’s just a line or two of code in your CSS. If you want to run an A/B test, a few lines of code and you can have a completely different call to action. If you’re designing for a client, and you comment your HTML and CSS sufficiently, they can make their own changes with a bit of coaching. Rapid development is so essential to many businesses these days, and and building a website with a code-first mentality (removing Photoshop) brings you one step closer to production with every change.

I realize that designers may be resistant to relinquish Photoshop, and I myself had been playing around in that program and figuring it out for years before I started doing any sort of real web development, but the days of coming up with a complete layout in Photoshop are over. For elements that can’t easily be made in CSS, it’s time to start using Illustrator (if you aren’t already). When SVG support becomes universal, you can have scalable images baked into your code and you will want to be ready when that happens. Not every designer will be willing to learn how to turn a wireframe with notes into HTML and CSS, but the ones that do will be at a distinct advantage. Think of yourself as an executive at a company that wants a new website. Between two equally talented designers, would you prefer the one that shows you an image file and says “how’s this?” and goes on to describe how elements interact, or would you prefer the one that sends you a link to a working mockup of a website with working transitions?

The days of mocking up a website in Photoshop from wireframe all the way to the step just before implementing it in HTML/CSS are coming to an end. How long before it happens is anyone’s guess, but I believe anyone involved in web design should be learning the skills it takes to cut Photoshop out of the picture. When the scale tips, bosses and customers aren’t going to be satisfied just seeing a mockup as a jpg file.

Agree? Disagree? Let me know in the comments or send me an email with your thoughts and I’ll get back to you.