If you’re making websites, chances are you’ve given some thought to what constitutes a responsive-friendly design process—and you’ve probably found that adding a mockup for every breakpoint isn’t a sustainable approach.
At least, that’s what happened at my company, Bearded, where we had spent years creating websites in Photoshop or Illustrator, having those mockups approved by our clients, then recreating those designs with CSS.
Until now. A few months ago, we stopped making static image-based mockups in favor of designing with code. This is not a new idea—heck, Andy Clarke was arguing for in-browser design in 2008. But new or not, you may still be mystified at where to begin—or feel unmoored and disoriented at the prospect of giving up the approach you’ve long relied on.
But fear not, gentle reader. Let’s take a look at our new mockup-less web design process and see just how easy it can be to get that Photoshop monkey off your back, and have a fresh new beginning with your old friend the web browser.
Let’s talk process#section2
Before we begin designing, we work with our clients to clearly define and prioritize the information that will go on the site. My first question is simple: Why do you need a website? Then I ask, what do you hope to accomplish as an organization, and what is your audience looking for? The answers to questions like these will help us define the functionality and information hierarchy of the site.
Hierarchy, hierarchy, hierarchy#section3
Once we understand the purpose of the website as a whole, we’ll apply that goal to something finite and designable, like the homepage. Before we even get to wireframing, we can express our site’s information hierarchy in the simplest possible way: as a numbered list. For a recent client, the American Association for Homecare, we ended up with a homepage list that looks like this:
- Branding statement: The primary emotionally communicative element of the design. It does not convey detailed information so much as give users an impression about what AAHomecare represents and help them identify with the organization.
- Variable featured content: Selected by site administrators, this area will include highlighted items from across the website such as events, pages, etc.
- Site navigation: This allows users to find the content they’re looking for.
- Membership: A brief list of the benefits of AAHomecare membership, followed by an invitation to apply.
- Events: A feed of upcoming events that contains vital information and links to the event calendar and event detail pages.
- Communications: Feeds of recent items from sources such as the blog, Twitter, or newsletters, with links to the source articles where applicable.
- Footer content: Includes links for some site navigation, legal pages, corporate sponsors, and social networking pages, as well as location and copyright information.
Without committing to any visual decisions about how to express it, we have created an accurate top-level informational hierarchy for the site’s homepage. We now know that—no matter what the homepage looks like—if it can correctly present this information, it will be a victory for the organization and the site’s users.
My other wireframe is an HTML#section4
Once we understand the site’s content and priorities, our first visual step is to create wireframes. But as you may have already noticed, shuffling text around a Photoshop file can be time-consuming and frustrating.
But you know what’s really great for laying out content in a way that accurately expresses its hierarchy? You guessed it: HTML and CSS! So we give Photoshop a well-deserved break, fire up our favorite text editor and WebKit browser, and start wrapping our content in semantic tags using a mobile-first approach.
When you only have a few hundred pixels of width to work with, priorities become even clearer, and hard decisions even more necessary. You may often find yourself asking, “Does this really need to be here?” By focusing on mobile first, we can have these discussions with clients earlier and more effectively. And the more informational load we can jettison now, the more our users will thank us later.
Once our mobile hierarchy is clear, it’s time to progressively widen the browser and consider more complex layout decisions. Each time we encounter a width where things begin to fall apart, we can add a new media query to adjust the layout.
To help us with in-browser layout development at Bearded, we developed a responsive grid system that allows us to quickly apply nestable column properties with CSS (or, more accurately, SASS and Compass). With these handy mix-ins at our disposal, we can quickly experiment with different responsive layout approaches without a lot of cognitive overhead.
At this point, our HTML/CSS wireframes are looking pretty good. And since we’re working with the same medium (code and the browser) throughout the process, we can naturally evolve our wireframes into the final designs.
When my wireframe grows up, it wants to be a site design#section5
It’s right around this time that we’ll take a brief diversion from our HTML to define some sensible style elements (similar to Samantha Warren’s style tiles or Sparkbox’s style prototypes). This is usually a small Photoshop canvas where we bring in the typography we’ve been working with in the wireframes and start experimenting with color, texture, and imagery. Once defined, we can use these basic visual building blocks to nudge our wireframes toward website-ness.
As we layer in more visual elements, we tend to bounce back and forth between our text editors and Photoshop. But Photoshop is no longer the primary design canvas; it’s now more of a sketchpad. Do we need to tweak our typography to perfection? Nope. Can we just throw a browser screenshot into Photoshop to mock up a new background graphic on the site? Sure! Don’t want to show this sketchy, half-baked PSD to a client? Not a problem—you never will.
Not only does this method reinforce a content-driven approach to design, but it’s also crafting something that’s useful to the final product. The HTML you created for your design comp will also let developers know what kind of markup you’re looking for from the CMS. And if you’re both doing your jobs well, it means the CSS you’re about to write can be dropped into the final site with minimal adjustment.
No longer will you waste away your afternoons pushing pixels in Photoshop, only to perfect a thing you’ll ultimately throw away and rebuild in CSS anyway. Some things are accomplished more efficiently in CSS, while others render more quickly in Photoshop—so we pick the tools that feel natural in the moment. But ultimately, everything ends up in the browser. That’s how we design it, and that’s how our clients view it.
Fear is the mind-killer#section6
“Oh yes,” you might be saying, “clients! How does this new mockup-less world fit into our design approval process?” Glad you asked.
Sign on the line which is dotted#section7
Sending clients in-browser comps is remarkably easy, as it turns out. We just e-mail them a URL. Clients can look at the designs in various browsers and on various devices, resize them, click links and navigation, and check out hover states. Instead of asking our clients to pretend that an image is a website, we show them… a website.
We always provide a permanent project URL with /v1 appended to it, such as aafh-css.heroku.com/v1. From that point on, version one never changes, and subsequent revisions are posted at their own URLs, like aafh-css.heroku.com/v2. This continues until we reach an approved version.
Because each version has a distinct permanent URL (we use Heroku’s free hosting for non-production environments like this), we can still have an agreed-upon number of revisions in our contract, just like we did with static comps. If the project requires more tweaking than we envisioned, it may be time to discuss allocating additional hours to the budget.
This also allows everyone to easily go back and review each comp whenever they want. When we’re done with revisions, clients get the same signoff form as usual. But in place of a file name, the final designs are specified by that version’s permanent URL.
Now, you may be wondering if your clients will accept this newfangled process. At Bearded we’ve had nothing but positive reactions so far. Our contact at AAHomecare even tweeted about it. I don’t know about you, but that’s the first time I’ve had a client tweet about liking the design approval process.
So that’s it. Signoff without a static mockup. Terrifying, right?
Send this part to your project manager#section8
“But wait!” you say, “what about the budget? Won’t revisions take longer? What if the client hates it and we have to start all over?”
That could happen. But couldn’t it happen with a Photoshop mockup, too? And even if we have to start all over with look and feel, it’s likely that at least the HTML and wireframe layouts are good. And really with CSS (and especially with SASS) there are lots of situations where editing in code is significantly faster than editing a Photoshop file. Take, for instance, changing the link colors or font selections site-wide. Faster in CSS or Photoshop? Yep. High-five, CSS!
Luckily my early hunch has thus far proven true. With AAHomecare, our design process took longer than estimated—by about 35 percent. Not bad, in my opinion, for a brand-new way of working. Meanwhile, our CSS hours were less than half what we estimated. So at the end of the day, our project was actually more efficient and more profitable without mockups. I know your PM will be excited about that.
Designing is coding is designing#section9
All of these changes to our process are also making our roles more fluid. With our designers writing CSS, where does design end and front-end development begin?
Overlap or not, there’s still something to be said for expertise. Front-end developers can collaborate with designers throughout the process. They review everything, refactoring redundant or overly complex code and removing vestigial styling. As they find problems, our developers keep a log of best practices for designers to review later, so they can improve their coding skills and avoid repeating the same mistakes in the future.
Our initial designs will also have features and views that we still need to elaborate on, as well as interaction enhancements that we’ve left for later. So not only is our design process more development-y, but our development process is becoming more design-y. As we all work together more, we’re also teaching each other about our respective specialties and becoming a more cohesive team. In my experience, that means building better internet.
This level of collaboration can lead to toe-stepping, so we use Git for version control. Git allows multiple people to work on a central repository of code at the same time, with methods to resolve conflicts and roll back changes when necessary. Technology aside, though, a simple “Hey, I’m working on the calendar CSS” often goes a long way—especially in an environment where collaboration and fluidity are the norms.
Ready, set, implement!#section10
How do we waste less time on throwaway products? How do we make the hours we spend in front of a computer more meaningful, and the end results more effective? These are all part of the same problem.
Responsive design gives us the opportunity to rethink our whole approach to designing for the web. We can stop designing “websites” and “mobile sites.” We can create flexible content delivery systems: sets of rules that define how our content will be presented as its context shifts.
Rethinking our process is hard work, and it may strike you as challenging—even daunting. But ultimately any of the hurdles we’ll encounter are just that. They can be overcome. The internet will change, whether we like it or not—and we must adapt with it.
And really, weren’t you getting bored anyway? Let’s do something better—for our workflows, our users, and our clients. Starting right now.
I’ve had a few clients come to me with a web experience based on a persona. Pick on of the 3, 5, 10 personas that best fit your personality/needs and we’ll have the site respond with content/communications designed for that persona.
I hate this approach. I find that it quickly falls apart or additional personas keep needing to be added as people find more than one visitor accurately straddles two or more personas.
Has anyone got any insight into a “successful” role-driven experience? Or are they all destined to fail?
This may be slightly off the topic of the article – maybe not so.
It’s a little off-topic, but that’s OK. 🙂
I agree that the role-driven approach can lead down the path of madness. I tend to make the assumption that everyone gets equal access to the same content, and that making people “choose their bucket” is wishful thinking at best.
I’d rather prioritize all the content across all users. For instance, if 80% of our users are more interested in Content A than Content B, then let’s prioritize Content A in the information hierarchy and let Content B require a little more digging.
You can’t make everyone happy all the time, right? So you may as well try to serve the most users you can, as well as you can, as much as possible. This may require talking to the client and asking them to make some difficult choices, but not making those choices at all will rarely serve their best interests.
MG
The wireframe/mockup/code mockup has been an ongoing shift/battle for a long time!
I’ve been on all sides of the equation, right from the insanity of project managers insisting that every single page is created in photoshop, through to the every single page should have a wireframe and right into the ‘design by the seat of your pants’ approach.
With the *correct* approach of designing in the browser, we’re seeing a blurring of roles.
The reality is – at least in agencies worth their salt – the boundary between front-end developer and designer is blurring, to the point where front-end developer roles may cease to exist. It will also mean web designers who can’t code will struggle to find work!
Most good agencies still find themselves in a bit of an impasse – with great designers who lack the finer frontend skills or, quite often, programmers who also lack them!
Here we see the lines blur again – traditionally, the programmers role has been the wiring and plumbing, leaving the decoration to the designer/front-end folk.
Not anymore. Top developers are expected to know both – heck, it’s an essential requirement for modern web development.
Fast paced, fast moving, ever changing – there’s often no time to clearly define roles. Everyone has to muck in, gather round, discuss and code.
I’m thankfully now at an agency who understands this.
Matthew,
Agreed! Ultimately designers need to understand the thing they design, which in this case probably requires some knowledge of code. Addressed this a little bit in a blog post here: http://blog.bearded.com/post/18437972041/the-medium-is-the-message
Thanks for contributing to the discussion!
–MG
I really have to agree with matthewtrew. The lines are really blurring! I found that I started web design with the browser, as the article stated, following the conventions of Andy Clarke, but as I hunted for jobs I found that they all want you to be a pro at Photoshop (my skills are good for web design but is this a progressive place to work?).
A graphic designer friend of mine is attempting to better himself at coding HTML, CSS, and even JavaScript in an attempt to procure a good job, while I am attempting to better myself with design since I started on the coding side. I call myself a web designer, rather than front-end developer, for the non-industry people, but I apply to jobs that have either or in the title.
Like you said, in this day and age of technology everything is going fast and we have multiple roles for one position.
Loved the article, by the way 😛
Thanks, Gianni! Good points, here.
I, myself, believe that things are accelerating far too quickly for any one person to have a handle on everything. That’s why I’m a firm believer in collaboration.
It’s also great that the web community is so open with information. I think everybody really gets that we’re all in this together. And thank goodness for Twitter. 🙂
–MG
Along the same lines of responsive design, I’m finding a big push to focusing on conversion rate optimization to feed into the design…to feed into the development. After all, hierarchy and customer-performance in a metrics driven company is centered around the SEO/CRO numbers, right?
Is this the return of the all-famous, but decade-shirked term, “WebMaster”?
I’ve come to stop working with freelance designers who don’t have experience with web development. Explaining backwards- (or device-driven)-compatibility to a print designer is futile.
CRO, responsive design, and accessibility are all functions of improving customer performance. It’s not a surprise they should all be tied together.
Thanks, Matt.
Great article… ish!
Why use PS?
It bugs me that forward thinking articles like this recommend designers switch to HTML and CSS for the majority of their design work but then still use Photo Shop!
Surely any forward thinking person is better off using Fireworks for any mock ups.
You know – the software that is designed for web designers to design web pages on.
Yea – the one that’s just like PS, but quicker, simpler and better for web work!
…but, we always find that the best way to get your responsive wireframes up to speed quickly is with pen and paper. Both PS / FW or CSS / HTML inhibit the designer from thinking about the design and put focus on the markup and grids or the boxes and shadows…
We always run out of ideas on paper then move to the screen with a better understanding of what we are designing.
Which tools would the client use to give their feedback on the versioned websites and HTML wireframes?
I’ve been using annotation software (Notable) to get client feedback on page layouts – and it’s been working well for both the client and I because we know exactly where on a page that a comment refers to.
Dropping in-place annotations would be a step backward for me: returning to the days of long emails with lots of descriptions of where a design element sits, and what it looks like – before any feedback itself.
Rocky,
To each his own! I simply used PS as an example because it has become such an industry standard. I know others who love Fireworks. Personally I couldn’t get into FW, and I always used Illustrator. It fit my style more – not sure I could have lived without tints for color swatches (which I guess is why I love the lighten/darken function in SASS).
Point is: don’t let your tools dictate your workflow. Choose the tool that makes sense for you on a given task, whether it was “designed for web designers to design web pages on” or not.
–MG
I completely agree that paper sketching can (and often does) have a place in the process. Particularly when it’s time to discuss blocking out the layout of elements, we may briefly (but importantly) pull out our dot grid notebooks and iterate different possibilities.
For us, this could happen at any point during the information hierarchy list / HTML / wireframe process.
–MG
At last a good staring point for responsive design. Thank you.
Even if it is slightly off topic I would like to comment that as important as it it to design from content there is also the additional aspect of context. Let’s take mobile as an example. Often small screens equal mobile devices, i e you often use them away from your desk, sofa or favourite café. You might want to show your screen visitor different content when they are actually right outside your store than when they scan your site at home. In that case context would mean near actually making a buying decision and combined with position (if available) very near actually visiting your store.
So I think responsive content design is a related, end very exciting, challenge.
Matt thanks for the great article. We have been using live html mockups for some time now and it has worked well for us.
I made a website. When I looked at it on a mobile phone it was small. I mean really small. But when moved the phone closer to my face it got bigger. I tried viewing the website on my big computer and when I made the window small it went small so I suppose it’s “responsive” – though I was no longer able to make phone calls. Is this normal?
Matt,
Good question! I know I saw a web app that did this a while back, but I can’t for the life of me find the dang thing.
This morning, though, a much simpler solution occurred to me. For annotated feedback, you could simply have your client take a screenshot and comment on it in Acrobat / Preview / etc. If you think this puts too much onus on the client, then you could provide multiple screenshot states yourself in a PDF. The good thing about client-generated SSs, though, is that it gives them a chance to assess and point out problems in any display width/height they’re viewing in, which ultimately gives you better feedback.
I suppose the point is: it’s really easy to get a static image out of a dynamic site, but not the other way around. 🙂
–MG
Benny,
Sounds like you accidentally the whole website. Is that bad?
–MG
Chris,
Dedicated mobile experience versus content parity across devices is definitely a timely discussion – and an issue that every project needs to address at its outset.
One thing to consider: even if you have a dedicated mobile (content) experience, why not make all experiences responsive? That way when someone tweets an m.url.com link from their phone and I get to it on my desktop, the resulting layout is still reasonable. (Same goes for desktop -> mobile, of course.)
–MG
I think this article saved me money. I was going to buy Axure (Interactive prototyping. Almost $600) I hoped Axure would work for me. But now I am very excited to try this approach.
Question
How do you manage your Git versions of sites and versions for clients like /v1,v2… Do you simply copy a specific Git commit and upload to v1/v2 for a client?
Thank you.
Really cool read. Heres my opinion. I think there are a load of graphic designers and artists. They all specialize in different things. Not every designer wants to code or even has interest in it. I for one have no interest in it. I’m far too busy designing for print. I run a design firm and print shop. We take care of hundreds of large and small business owners. It doesn’t make sense for me to be someone who codes. If you have no interest in it you won’t have fun and enjoy what they are doing. If you don’t enjoy what you are doing than you’re never going to make anything great. I work closely with my developer to create great web pages. He does what he does best which is code. I do what i do best which is make art and design. Ask him to draw you a stick figure and he couldn’t do it. Ask him to make a great branding and identify package and he falls short. He’s not an artist. He writes code and knows how to make the art i create function. If the artist has the mindset of having the art function and even the most fundamental understanding of what code does, a developer and artist can work closely together. It isn’t rockset science. I think these mindsets are two different things. When the brain is broken down into right and left we know that the left brain processes information. The right is the arts side. When we think of code we think of information. Processing, layers, strings, language. I think it’s much more effective to be a master of a specific tool set and not try to do everything. I think what comes out best is when you take a team of designers and a team of coders and they work together. They have meetings so they know what they can get out of each other. Not every designer wants to be a webmaster or developer. I think web design and web development should be tied close together but be done by different groups. That’s when the magic happens.
90% disagree with this. This seems wrong, unless the intent is to build a half-prototype and then build the actual site from scratch.
I’ve driven down this road often before, and it’s hard enough to pivot a build to a client’s whims from a scratch-built site without making a spaghetti tangle, much less to start with a sort-of-half-understood-let’s-figure-it-out-as-we-go-along prototype which is then expected to magically morph into a well-built sturdy site. You’re asking for a bunch more time and money spent than you need to spend.
The 10% I don’t disagree with is if you’re working with a group that understands the potential pitfalls of this process, and builds that in as part of the process (and bills accordingly). If you can all agree that the dev mocks are something you won’t actually be using, then by all means go for it. Otherwise stay away.
I’d also like to point out that developers have made it really easy for designers to make sophisticated Rich HTML 5 pages with web builders. Of course for the big boy stuff like complex websites like facebook, youtube, ect social networking sites that take up a lot of servers you’d want a development team. But Website builders like wix are a great tool. A lot of people actually say that oh you can’t make anything good with that. Which is not the case at all. Designers who don’t know a bit of code can make incredible HTML 5 websites with wix that are also responsive with mobile tied right in. For the small business owner who wants a simple website, for the average consumer looking to have a website for them self, a good designer who knows the principles of design and one who is a great artist can make very good use out of a builder like Wix. Especially now since they have moved to HTML 5 and have pretty much a unlimited amount of layouts and things you can do. You can even let a developer implement custom code into it. Now when we sit back and think about it, it was developers who made wix come to life. People in the development community did this to make it easier. There will always be a need for a real developer. That’s never going to change. At the same time i don’t think website builders like Wix take away from developers at all. I think it benefits all designers and graphic artists. We don’t all want to look at code. We don’t all want to know code. It’s not necessary. Plus with how fast technology moves eventually code will be taken over by these experiences in the browser. Full blown apps in the browser will take away code so the user never has to think about it. The point of technology is for it to fade to the back. Code should fade to the back. There will become a way where code is bypassed all together when it comes to the web for simple things and average websites.
I expected the aahomecare.org site to be responsive and was surprised to find a fixed layout and somewhat painful leading. What happened?
I agree that the role-driven approach can lead down the path of madness. I tend to make the assumption that everyone gets equal access to the same content, and that making people “choose their bucket” is wishful thinking at best.Like you said, in this day and age of technology everything is going fast and we have multiple roles for one position.
Thanks, Lex!
We’re just using different folders for v1/v2/etc. We copy and paste v1 and rename it v2, then never touch v1 again.
I know it’s a little quick and dirty, but it gets the job done. 🙂
–MG
Jack,
I agree that specialization is very important, and that no one can do everything well. I do think that in the web design discipline (which is distinct from the graphic design discipline), there is necessarily some degree of overlap. Just as print designers needs to understand enough about the print process to design printable work, a web designer needs to understand enough about the web to design websites well. In my opinion that means some degree of coding knowledge.
And let’s get real for a second: calling HTML/CSS coding is a bit of a stretch. It’s not C++. It’s not even PHP. It’s a skill set that is completely within the grasp of most designers.
And because these skills are things the Bearded designers already had, it made sense to shift our process this way. Because of those changes, we’re seeing benefits.
That doesn’t mean you have to work this way, of course. I’d really encourage you and everyone else to just reexamine your process, and see what about it does and does not make sense right now. Getting stuck in ruts is easy; don’t just do it because that’s how you do it. But if your process seems to be working for you and you don’t see any problems, congratulations! Keep up the good work and enjoy the bounty of your labors.
–MG
bobudd,
I definitely do not promote “sort-of-half-understood-let’s-figure-it-out-as-we-go-along” design processes. This article focuses on the design phase, and did not have the room to discuss the research and planning phase. I did outline some of that process in an article for .net Magazine a while back: http://www.netmagazine.com/features/dont-go-it-alone-collaborative-web-design
… but the key is to have a good sense of purpose, scope, and feature set before you dive in.
Planning is absolutely essential to a successful web project, regardless of the tools we use to create our designs – otherwise we’re just spinning our wheels.
–MG
Jon-Paul,
I think the link you’re referring to is to their current live site, which is as of this post AAHomecare’s old, fixed-width website.
There are links further down in the article that show various stages of the redesign. Once AAHomecare is finished with content entry, we’ll be deploying the new site to that same URL.
–MG
I love this concept of developing whilst designing. I can see the benefits already. It would be interesting to see how many places adopt this approach.
Naturally there would be a lot of photoshop involved anyway with developing logos and images, and I personally am not quite ready to make that shift with my design / development skills.
Still, I love the whole versioning system that keeps clients in line with their contracts and keeps them happy at the same time. Also, I love the Bearded website!
Thanks, Mike, glad this was useful to you!
–MG
I love this concept, but feel like my clients still need a visual. Wireframes are great for quick real estate decisions, but photoshop will always be my bread and butter… at least for now!
Great article!
Eric
I was just wondering what you guys do if you are in competition against other agencies? Do you present a complete prototype or do you still elaborate PSD mockups for these?
Eric,
But we do show them visuals! The wireframes are for internal purposes, but a client sees this: http://aafh-css.heroku.com/
For me, that is a much more communicative visual than any PSD.
MG
Eva,
As an agency, we don’t participate in spec work. Personally, I believe spec work is harmful to our industry, and that we should be paid for our time.
You can’t ask three contractors to work on your house, then proclaim one the winner and not pay the other two. Web designers are skilled workers, as well, and our time is worth the cost.
MG
Great article, I’ve always favoured mocking up in the browser. However there are two parts of my process that I’ve yet to refine that I’d be very interested to know how you deal with:
1) Have you any suggestions on how to prevent different mock up version’s code spilling over into each other? I find myself constantly having to refactor the code with a fine tooth comb, which can be quite messy opposed to coding up a photoshop document which tends to be a one hit process.
2) At what point do you introduce a CMS/back end? There is an argument for doing it right off the bat, having something like WordPress linking all your mocked up templates together, providing content to style, injecting WP generated code with all the classes you want to be targeting etc. However one could also argue that this stage of the process should be reserved for the final version of the site, with there being a necessary separation between the creative and technical elements…
I would love to use a similar process where I work. Hopefully soon!
Good article! Thanks!
FYI, in FF17, the page at http://aafh-css.heroku.com/ has an issue at around tablet width where the email signup box slips up along the right side of the large main image and becomes unusable.
We have struggled when designing responsive websites at our marketing agency. Our traditional process is that the graphic designers design the websites then give the designs to the web designers to cod. With responsive webdesign I now feel the web design should give the graphic designer their a live templated version of the website that the graphic can be designer around. But where odes the customer fit into this process?
I love this approach, but of course, it requires buy-in from all the other members of one’s work group, including setting up and using Sass/Compass. I’d love to try this, or Less, for that matter, but it seems to me that that wouldn’t work unless everyone on the web design/dev team all used it. Am I wrong?
Awesome! Can’t wait to implement this approach on my next project.
We have been successfully trying this approach. The web design and dev teams are co-existing happily.
@ Matt, totally agree re No spec work and great analogy about the Architect.
From my understanding, what Matt is defining is a process that saves time because designers code directly as CSS for layout and interactivity and then touching up the design so that the client can experience it
What the client experiences is actually 3 things
1. Look & feel
2. Layout
3. Interactivity
If you break it up, there are actually 3 things to approve
Doing it all one go isn’t wrong, but its alot of effort without knowing whether or not the client would like it or not
It’s like a blind date where your best friend says he’s planning to introduce the girl of your dreams without qualifying your interests first
If i were to break it off as a science, the equivalent in human terms would be beauty, attitude, and whether we get along
There is a certain look that a man looks for, and that is a big attention grabber. This is why we work on look & feel first
Attitude determines prerequisites that determine our moral boundaries, e.g. religion, vegetarianism, an aversion to politics or what not. They make the relationship tick. (And hence why layout is instrumental in solving problems in the workflow)
Getting along with someone (interactivity) on the other hand is the nail in the coffin or the key to your heart as it defines chemistry. If for some reason you hate what you see, and dislike her attitudes but you seem to laugh together, it just means that you can be great friends, but you wont have children with them because it doesnt solve your long term goals of settling down (well for me marriage is about having children and growing old with someone i care for)
But of course if she meets those criteria, she would become the perfect girl that is hot, has a great personality and doesnt get on your nerves and actually makes you laugh all the time (unrealistic, but it’s always a dream)
From my opinion, this approach talks about time savings of doing all 3 in one go, and getting the you to choose and comment on the girl your best friend has chosen at the blind date at the first glance
For me, I would have worked on looking after a list of female candidates with a look that i know he can live with and cross reference that with a personality i know he is comfortable with.
After that, with maybe a list of promising 3-4 candidates who meet the above, i’ll let them have a blind date and then leave it up to chemistry (interactivity) to determine the hit or miss
I can’t say it will work most of the time, but the likelihood of success increases because we have qualified the candidates through an elimination process
Matt’s technique works well if you can master all 3 attributes and mix it together well enough to always guess what the client wants correctly most of the time (which is possible to pull off if an art director gets to work with a designer who lays out stuff in CSS and touches the look & feel up with elements created in Photoshop or Fireworks after the layout is done ).
In the absence of that, it creates a bigger drain on resources each time the client says no.
In an utopia where all team members are as equally gifted in all disciplines as one another, this process is actually brilliant as each team member can pretty much be Rambo and a one-man army to take on the bad-guys.
However utopia as always is a dream. We acknowledge that dream, and strive to achieve it. Hopefully one day, if we work hard enough and plan for it, it will become closer to reality
In the meanwhile, our process is really simple (Not fancy, but it works)
For look & feel we try to define brand elements visually to dictate taste and aesthetic appeal based on the client’s profile, customer base and brand positioning for appraisal, so unfortunately this is almost always a storyboard with several moods to it
For layout we do a wireframe, experiment with several layouts to solve workflow issues or improve cognitive understanding. I acknowledge that Photoshop isnt the best tool for this. This is why i use powerpoint (gasp ^_^) because it’s so simple that when i share it with my design team, they can literally just copy and paste it out when they set it out in fireworks or HTML and not redo things from scratch
Honestly layout & design is heavily intertwined, but they are really separate problems to be dealt with.
When I break it up as separate issues, I can get the customer to decide on a aqua-jelly looking theme or a tree-hugging nature theme for a client and then still suggest layouts that solve a business process as a separate problem.
Last but not least, for interactivity, this is where we actually build the solution and let the client play with it. For us, it actually becomes faster at this stage because most of the things have been set in stone as they have been approved.
We would just need to make the interactive elements more engaging, intuitive and spectacular but honestly this is really just icing on the cake.
Anyway I think Matt’s approach is a very workable solution for very mature teams with skillsets that cross disciplines. For more traditional teams where the players dont do what the other team member does, perhaps the traditional approach would be more suitable as it breaks problems into tasks that can be solved by disparate teams.
Alternatively, if Adobe gets their act right, they start releasing a dreamweaver that has the same tools as fireworks and actually vomits out HTML 5 that defines layout, style and interactivity (like Flash) with a timeline ^_^ and then all of us can just work off the same material rather than passing it back and forth
One huge draw back that was pointed out by tomliv is that by creating a HTML mockup, sending a URL to a client for demo, you will most certainly end up in discussions regarding browser compatibility issues, something that’s not what you want on the table when you want a DESIGN approved. At least you need to be aware of this.
With a static image or series of images you don’t have to deal with browser related issues.
Suggesting that there is ONE way to do this and all other ways are dumb is just wrong. All designers, clients and companies are different, just because you hate Photoshop doesn’t mean it sucks and just because designing in the browser sucks for you doesn’t mean it sucks for everybody.
Personally I prefer to do my web designs in Photoshop as it’s a creative process that works for me and when you get graphic heavy you really need to visualize the design as a whole before you can export .png files for backgrounds and icons and graphics etc.
The french translation of this article has just been published : http://www.pompage.net/traduction/conception-responsive-obtenir-validation-sans-maquettes
Creating a cross-browser responsive designs with HTML5 & CSS3 media queries has worked well. Truly Responsive Web Design is the best for the future.
Really like the article and agree completely. We have been doing this for quite a while. It works particularly well for sites that have a lot of content, because you get a really good view of how the content effects the design. The thing that was doing our heads in was getting structured feedback from clients , we tried notable but found that ‘state’ and browser and screen sizes etc weren’t captured by the notes and we had no way to explain to the clients what we had changed in a new version. So a bit of a shameless plug here, ( but I think it’s very relevant ) we built webseam. It allows you to put up a website, the client comes in and can browse as normal, when he finds a problem he can add a note, make a content change, make an image change and suggest a move. The developer gets a structured list of issues each with a code snippet and a link to the relevant part of the website. When an updated site is available the system figures out what is new and highlights those things to the client. We are in beta right now and would love developers like you to have a look! Please excuse the plug but we think its pretty cool and really helps with the process you set out in this post
MG – Thank you for this awesome article! I’m a total newbie to web design, just starting to consider how I would work with a client, so most articles on collaborative web design processes go over my head. But your article was understandable, and I feel like I have a new handle on how to approach my first design process with a client later this year. Thank you!!!
Great article..watched a talk given by Brad Frost and he referenced it so here I am. I wanted to know, with the changes in Photoshop now giving you exportable CSS, are you using it more or less in the process ? It seems Adobe is listening to developers/designers in this regard.
I want to say. It is really nice job. Thanks
Nice post.
I have been using Balsamiq for internal prototypes and mockups.
It was a useful way to put ideas on paper quickly.
Then, I would use Invision to create simple interactive prototypes with Balsamiq designs (low fidelity).
Some months ago, I learned basic HTML and CSS.
Using a text editor to create pages was too slow, though.
Since I started using Webflow (https://webflow.com) it’s easier and faster to create prototypes in HTML/CSS/Javascript than the combination of Balsamiq + Invision.
So, my workflow now is:
1. Writing user narratives to establish priorities.
2. Brainstorming layouts with pen and paper.
3. Using Webflow to create interactive prototypes.
Both css and html should work together to have great outcome to your web design. 🙂 i have a new project for web design which is Adjustable beds.com and that’s purely CSS and html design.
Adjustable electric beds & rise recliner chairs – Price match promise on our adjustable beds & chairs – we will beat any genuine like for like quote and give a further 5% discount if you can find cheaper.
I would prefer HTML 5 also this is great there’s a lot of new elements where you can customize your website, i’ve used to do for my personal site which is castings.com and stainless steel canopy.com it was fun doing html5 on my web
FOR Me css is the best for web designing
here’s my site
IT Support Birmingham