CabGFX

Stay shipping

2013-02-04T00:00:00+00:00

We’re clearly a bad judge of our own creations. We should just put it out and let the world decide. —Derek Sivers, one of my alltime favorite bloggers and a great inspiration, shares this wonderful little nugget in an old, but good, post on what is obvious to you, is amazing to others.

A good reminder to stay shippping and consistently improve.

Stop dissing your clients

2013-02-01T00:00:00+00:00

Since I first read Don Norman’s classic The Design of Everyday Things, one particular takeaway has stuck with me ever since: if people fail to understand my design, the fault is mine, and mine alone. As the designer, I am responsible for conveying the meaning and intended use of the interfaces I put into the world.

Similarly, as a professional, I must assume full responsibility and take control of the process, in which I engage my clients, colleagues and stakeholders. Deferring responsibility, avoiding tough decisions, failing to take preemptive measures, and other acts of unprofessional conduct, all point to the signs of an amateur at play.

Perhaps you can understand why, then, I cannot come to terms with the fact, that we, as an industry, seem to accept the phenomenon of ridiculing our clients in public, albeit anonymously.

I saw a tweet from Frank Chimero, which completely sums up how I feel about this practice:

I get really bummed when designers create projects that make fun of their clients.
— Frank Chimero (@fchimero) 30. jan. 2013

Please. We are design professionals. Imagine hiring someone to carry out a job, which you did not feel equipped to take on by yourself, only to find out later that your questions, requests and enquiries had been posted online, with the sole purpose of making fun of your apparent ignorance (completely ignoring the fact that said ignorance is what created the job in the first place). Wouldn’t sit right with me, even if there was no mention of my name, or anything else that could otherwise identify me or my company. So why should my clients feel any different?

Yes, I’ve had my share of professional relations gone south, and I can certainly relate to most of the scenarios described in many of these “silly client” stories.

Yes, I’ve been talking shit about a client or two, behind their back, to a coworker. I stress that last part — to a coworker. Everyone needs to ventilate frustrations every now and again, and it might very well be legitimate woes, but you should never take it to the streets, so to speak.

And yes, some people really aren’t very good at comprehending what it is that we do, or at least they don’t want to. But perhaps this shouldn’t define how we think about all of our clients? Perhaps it is simply because some (a few) people just don’t act like professionals at all?

Then, perhaps, the real issue is: Don’t work with amateurs. Don’t work with anyone who doesn’t respect you, your craft or your position as an equal partner in a professional relationship. Learn to gauge your client’s initial level of engagement, and if it doesn’t meet the standards you hold yourself to, disengage. It’s that simple.

I’m not saying you should just fire customers willy-nilly (bad idea if you’re in it for the long haul), and I’m definitely not advocating an elitist approach to how you conduct your business. However, No is such a powerful word, and I’m beginning to see how, when employed with good sense and respect, it can be truly liberating.

Don’t do work you can’t put your name behind; go hard or go home. Always seek to better yourself and the people you work with. Listen. Learn. Educate. Work to become a trusted ally, not a commodity, to your client’s business, and you will be rewarded with less hassle, fewer hiccups and more good work to ship. After all, isn’t that we all set out to do?

I absolutely love what I do. And I want the people I work for to feel the same way. That’s my responsibility, not theirs. Similarly, I love working within this industry of ours. We are at the very forefront of the times we live in, and people trust us to lead them into new ways of doing business. Coming off as a bunch of snotty hipsters will only stifle our collective progress, instead of moving us forward. We can do better. That is a common responsibility we all share as professionals.

Comments are open, ditto twitter.

Related reading
Stupid Is As Stupid Does — Andy Rutledge
Your Clients Are Not Stupid — Nathan Ford

Jason Grigsby on responsive app design

2013-01-04T00:00:00+00:00

By making a decision to design solely for a “desktop UI”, you are creating technical debt and limiting the longevity of the app you’re building.

Jason Grigsby wrote a great article on how the design paradigms of desktop, tablet and phone UI are converging.

You should read it now: Responsive Design for Apps — Part 1

Meet Votes.io, our Rails Rumble 2012 contender

2012-10-16T00:00:00+00:00

Votes.io is instant feedback. Quick polls. Fast answers.

So the Rails Rumble 2012 is a wrap, and I’m really proud of what we’ve built.

Votes.io is instant feedback: create a poll, share the short link and watch the results tick in, beautifully rendered in real-time.

Embracing constraints

Working within a 48-hour constraint enforced a focus in the team on getting things done. Most of the team members, including yours truly, have toddlers at home, further enhancing the time constraints and the focus on being über-productive.

Between diapers, family dinners and that pesky need for sleep, the task was simple: create a simple app that does one thing well.

Removing friction.

We deliberately chose to not provide any account management or poll administration. Creating a poll should be dead simple — write a question, add some choices and share the link. Done.

Made a typo? Forgot to include a choice? No problem — just create a new poll. No messing around with deleting, editing or unpublishing a poll.

Sure, there’s a lot of good reasons for tying votes to a user, and letting the creator go back and edit/update polls. It just wasn’t right for this type of poll system. Votes.io was built for immediate responses to simple questions, and as such, each poll is shortlived.

The premises of the contest was also a factor in this decision. Judges can’t be expected to invest a lot of time in each app, considering there’s roughly 300 apps competing. I fear a lot of great apps in the Rumble will suffer a lack of votes, because of this.

Designing the UI

Use cases for Votes.io: Vote for tomorrow's lunch, get audience reactions and sending polls in emails.

Our canonical use case is a speaker who creates a poll, prior to a presentation, and includes the URL in her slide deck. Then everyone vote simultaneously at the event and watch as results update instantly.

This focus on doing one thing well shines through in the UI, especially on the homepage. The interface is obvious and needs no further introduction:

Votes.io homepage

Getting started

I initially hashed out some simple flows, to get a feel for the screens we’d need and what elements would be required to support the interactions:

The flows needed for a minimally viable product

After a couple of back-and-forths with the team, we started building the app. The rest of the team took on Rails and data modelling, and I started building the UI. For such a simple app, a quick sketch and then straight to code, felt like the right approach.

Quick sketch in Draft for iPad, post to Campfire for a quick discussion, then back to work. (In danish, sorry.)

We didn’t have time to design the UI from scratch, and decided to build off of Twitter Bootstrap. We’d get battle-tested components for free, eliminating potentially time-consuming issues. Bootstrap also provides a simple, pragmatic foundation for responsive design—a crucial factor for us.

Good copy is everything.

Feature freeze

At the end of Day One, we’d achieved our goal for the day: have a working, usable app. Still rough around the edges, but feature-complete. Create a poll; get a short link; watch results update in real-time, visualized in three different charts.

We started Day Two polishing the UI, refining copy, refactoring code and squashing bugs. We didn’t quite manage to make all the visualizations really sing, so we decided to kill one of them. It’s still in there, you might be able to find it ;)

As the end of Day Two was approaching, the app felt polished and we decided to ice the cake. We anticipated a lot of mistyped shortlinks (think thumbs vs. touch keyboards), so we added a little easter egg to our 404 page. We also added some featured polls to the frontpage.

The cherry

With less than 3 hours left on the clock, I figured we could use a logo. I got busy with my Wacom stylus and Paper for iPad:

Combining bar charts to form the letter V

And we had a logo. Admittedly, not the best logo I’ve made, but considering my caffeine level, it’s alright. I used Jason Zimdars’ handy SCSS mixin to serve it @2x-dead simple.

We went trough the app, securing all pitfalls, tagged the repo and exhaled. Signed, sealed, delivered.

Recommended.

This was my first time participating in the Rumble, and it’s been great fun. I had a chance to try out some new techniques and just geek out for 48 hours. Bliss.

If you’re a designer, you should definitely try joining a hackathon—it’s not just for programmers. You might even pick up some new coding skills along the way, I sure did.

Huge props to the rest of Team Votes.io: Jacob Tjørnholm (@chopmo), Laust Rud Jacobsen (@laustrud) and especially Jakob Skjerning (@mentalizer) for inviting me. Amazing what a simple retweet can lead to.

Try out our app at votes.io and if you think it’s good, please vote for us—thanks!

Rails Rumble 2012

2012-10-12T00:00:00+00:00

This weekend (Oct. 13—14) I’ll be participating in the recently resurrected Rails Rumble, along with the amazing backend chops of Jakob Skjerning (@mentalizer), Jacob Tjørnholm (@chopmo) and Laust Rud Jacobsen (@laustrud).

Obviously, I’ll be doing the UI and a lot of the frontend of our entry. I definitely look forward to working with, and learning from, these guys.

Can’t say much about our plans for the app yet, but you can follow along and root for us on the Rumble entry page.

Oliver Reichenstein on design by committee

2012-08-20T00:00:00+00:00

Nothing is more destructive to good design than group thinking and collective decision making. Why? As I said, to most people good design is invisible. Group decisions focus on the visible, bad aspects of design. –from a lengthy interview on The Verge

Getting started with web development

2012-05-03T00:00:00+00:00

I was asked the other day to compile a list of resources for a friend that wants to get started designing & building for the web.

As I was compiling the list, it dawned on me how far we’ve come. Not long ago, resources were scarce and mostly HTML for dummies-type-stuff. Now there’s an immense amount of material available, and I’m especially keen on the recent rise of interactive courses. Sites like Treehouse, Code School and Code Academy are really pushing the envelope in this space, and I can only imagine where we’ll be 10 years from now.

The following list is what I came up with initially, and I’ll be expanding it over time. If you can think of any resources I haven’t listed, please suggest them in the comments below. Think of it from the perspective of a complete beginner, with no prior understanding of how a website is built. Thanks.

Interactive courses

Codeacademy - The title says it all: Web Fundamentals
Treehouse - A bit more advanced, but still great if you’re just getting your feet wet.
Code School - Advanced frontend coding (HTML, CSS and Javascript) and programming courses.
Code.org - Simple courses to get your feet wet, plus a whole slew of additional resources to dig into.
Udemy.com - Since I first published this, a lot of sites have added tons of great courses, materials, etc. Udemy especially have quite a catalogue to peruse these days.

Online tutorials & references

SitePoint - good, basic references & resources to get going. I haven’t gone through them all, but there’s generally high quality to be found.
HTML5 Doctor - a great site for understanding the semantics behind the new additions to HTML, and how, when and where to apply them. It does require an understanding of the basics of HTML, however.
Udemy - recently posted a good, thorough and up to date introduction to HTML. Great primer for anyone looking to start with the very basics.

Books

I had trouble finding the best entry-level books on website design & development, so the books on this list all require a general idea of how websites come to be.

Don’t Make Me Think, Steve Krug - the usability bible. Mandatory reading.
Bulletproof Web Design, Dan Cederholm - a great resource for applying best practices to the way you build websites.
Designing with Web Standards, Jeffrey Zeldman and Ethan Marcotte - I’ve never read this myself, but I’m pretty sure the authors earned some of their stripes with this opus.
Every single book from A Book Apart - every single one is excellent and will prepare you for building the websites of tomorrow.

General thoughts on web design & development

This list could easily go on forever, but these are some of the people/places I’ve found to consistently post great articles on how to build better software for the web:

A List Apart
Ryan Singer
Des Traynor / Intercom blog
Joshua Porter - both his personal blog and the co-op 52 Weeks of UX
Method & Craft
Brad Frost

Finally, you should check out my earlier post on how to maximize your productivity when you start designing that awesome thing you have in mind. Oh, and remember: sites with pictures of funny cats will never go out of fashion. Now go and build something!

A review of the new Basecamp

2012-04-03T00:00:00+00:00

TL;DR The new Basecamp from 37signals is out, and I’ve been using it for about a month now. It’s an amazing product and, pending some minor tweaks & additions, poised to become the new standard for project management tools to adhere to.

Most project are small and short. The original Basecamp was overkill for most kinds of projects. The new Basecamp is perfect for projects of every size. Jason Fried, in the launch post on Signals vs. Noise (company blog).

I’ve used the original Basecamp (now renamed to Basecamp Classic) for a long time and I always had mixed feelings about it. It did a lot of things well, but as a whole, it often felt like a drag; keeping Basecamp updated became a task of its own.

Boy, has that changed.

Rewrite

The team at 37signals decided to start from scratch with the new Basecamp (initially dubbed Basecamp Next, or BCX, for short), and launched it as a separate product from the Classic edition, which is still available and maintained. That is a bold move: it takes balls to decide to rewrite your flagship offering, one that’s been profitable for 8 years and counting. Gotta respect that.

It’s interesting to see a company with the clout of 37signals take on The Big Rewrite, and they’ve done a very good job. Chris Bliss of VM Associates wrote a great post about their execution, which he thinks is (sort of) revolutionary:

Once the product felt dated (after ~8 years, or roughly 3 cycles in the old model) they built a brand new product from the ground up. They combined the best of both worlds: the quick feedback loop of the new model with the “ground up” approach of the old model. Brilliant.

Focus & Simplicity

The number one reason I love BCX is how it exudes simplicity and feels powerful at the same time. Every feature clearly had to fight to make the cut, which leaves a razor-sharp focus on getting things done.

A lot of people are up in arms about features from Classic that’s not in BCX, such as private items, time-tracking and Milestones (to-dos tied to an event) – all features I rarely used myself, and the app seems better off without them. It feels like a lean and focused app that complements, rather than compromise, my workflow – checking in to catch up or post an update is now quick and effortless, which was rarely the case in the past.

Snappy UI

Part of this is because of the speed and responsiveness of the interface – Basecamp is stupid fast, due to some solid engineering with sophisticated HTML5 pushState wizardry on top of a ridiculous amount of RAM used in an interesting approach to caching. Did I mention how fast it is?

Attractive things work better, and the new Basecamp is testament to that. The interface is gorgeous and a joy to use, mainly because of how unobtrusive it is. Generous use of whitespace and excellent choice in colors & typography combine to form a layout that’s pleasant to work with and most importantly–gets out of my way.

There’s a lot of great details in the UI, but one that stands out is what 37signals calls page-stacking - pages as sheets of paper. This is a truly innovative approach, and it works really well. This video explains it way better than I ever could (jump to 3:20).

Human-friendly

Too many people are slaves to their email, but I totally get why most people stick with it; it’s easy and it Just Works (most of the time). I’ve tried suggesting tools like Basecamp to these people, with the same outcome every time: busy people can’t be bothered to take a new system in until the benefits are proven.

Now, people don’t have to adapt to a new system at all if it doesn’t work for them. Basecamp works incredibly well as a transparent layer on top of the regular flow of emails - I’ve been using it with my team at autobutler.dk since launch, and we’ve had none of the pushback from the last time we tried to introduce Basecamp (when only Classic was available). Some team members use Basecamp, others just use Gmail, and all of our progress on projects is recorded and gathered nicely in BCX.

This is in large part due to a new feature called Loop-in. Here’s how it works: you post something in BCX, and want to let others know about it. You tick off the usual suspects to be notified, and in addition to that, you can notify (loop-in) someone that’s not on the project by adding their email to the list of recipients:

The new loop-in feature in Basecamp

They’ll get an email with the entire conversation in reverse chronological order, and can just reply to that email. Business as usual. This works really well, even more so for when you want to include someone that’s not even a part of your company.

Overview

Another great feature is the Daily Progress page, accessible from the main navigation. This is the successor to the Dashboard in BCC, and is way better - it was called Timeline during the beta, which describes what type of overview it provides.

This global overview is complimented by each project’s Catch up on recent changes page, that lists activity day-by-day. Additionally, almost all actions in Basecamp are covered by an audit trail and undoable history, so you quickly become confident that data won’t ever wind up missing, once it’s been put in Basecamp.

Another thing that works well is how Discussions are aggregated on the main project page from all comments, on all items. This is especially great compared to the old Dashboard and Messages index, both tedious to go through when you just needed to get an idea of what was currently being discussed.

You can also have a daily catch-up mail sent to you at 7am with yesterdays progress and as always, you can subscribe to RSS feeds of your projects activity. All of these things might seem a bit daunting at first, but they’re not. Apart from the occasional overflow of emails, the team at 37signals seems to have struck a near-perfect balance with regards to how and when you catch up on a project.

Quirks

As I mentioned in the start of this post, there are some parts of the new Basecamp that rub me the wrong way. But the fact that they’re all minor details, speaks volumes about the quality of the first release.

First of all, the administration of people and their permissions/project access is a bit wonky. For example, new invitees are granted permission to create new projects by default - that surprised me a bit, but it’s not that bad. However, when compared with the fact that new projects they create aren’t initially visible to me, an Administrator and the account owner, it becomes weird. Regardless of your role & permissions in the account, you can only see projects to which you’ve explicitly been granted access. That just doesn’t feel right, especially on accounts with a set project limit.

Generally speaking, I sometimes get lost navigating between sheets (pages). I tried narrowing it down to a specific example/scenario, but I couldn’t – it’s just one of those things that’s hard to explain until you try it yourself.

I might be biased from using the Classic version, but I initially thought Todo-lists weren’t sortable by dragging and dropping - there’s no visual clues that you can do this on the items in the list. This goes for the entire list as well - they both afford clicking much more than dragging.

It also really bugs me that there’s no apparent way to delete files - it’s not a problem right now, but it will be once I’ve used a sufficient amount of the storage in my account.

Finally, I miss some mobile optimizations - but given that this is version 1.0, and that the new API was recently released, I’m confident that we’ll see some efforts in this area soon.

9/10

Overall, it’s been a long time since I was this impressed with the initial release of an app - the high expectations I had, have definitely been met.

I had the pleasure of participating in the closed beta, and it’s been really fascinating to get an inside peek of how 37signals prioritize their efforts and push back on feature creep. Their approach to building a great user experience leaves no room for compromise and it shows in the product.

If you haven’t used Basecamp before, or if you’re still using the Classic version, now is the time to switch. With a 45-day trial and a price starting at $20, it’s a no-brainer.

Removing waste in your design process

2012-03-16T00:00:00+00:00

Sketching, wireframing, Photoshop and HTML/CSS each have their place in certain phases of the process. In this post I want to give you an idea of which method to employ and highlight the advantages and pitfalls of each.

When I work on a feature or flow, I actively question my thoughts & decisions: how does this get the job done? – does it make sense? - will it be easy to code? etc. If/when I catch myself making little or no progress towards a solution, I’ve found that it’s usually because of a lack of feedback. As designers, we all know the feeling of “going in circles” and I consider this a wasteful part of the process.

Iterative design is all about spending as little effort as possible -but no less– to make an informed decision and then ship the work, so that our feedback loop(s) may tell us where to go next. So what exactly constitutes “as little effort as possible”, and how can we minimize waste in the design process?

Sketching

A simple sketch is the natural place to begin exploring possible solutions. Most of us keep a pad and pen readily available at all times, and for good reason – this is by far the fastest way to visualize your thoughts. However, the low fidelity of the good ol’ sketch can sometimes hinder your ability to see if the direction you’re taking is worth pursuing.

A little sketching is an exploration, a lot of sketching is a procrastination Ryan Singer

Sketching should be for quick explorations of abstract concepts, isolated UI elements or for outlining high-level flows (how does one get from A to B, what screens are necessary, etc.)

The sketch is also as a great vehicle for bouncing ideas off of co-worker(s). These discussions then serve as a litmus test of how well you’ve thought through the proposed solution, and especially if it’s time to move on to a higher fidelity. You should stop sketching if a teammate expresses the need to see things in greater detail, in order to see the big picture.

Remember, your sketch is just that: a doodle. This is why being able to recognize when to sketch, and when to stop sketching, is crucial.

aside:

I personally prefer big, cardboard-like paper and a chisel-tip pen (danish shop for cheapskates, Tiger, has some great pads at DKK 50,-). This keeps me from thinking about the finer details too soon – much like premature optimization in programming, both of which should be considered wasteful.

I’ve tried out lots of iPad apps as well and found Penultimate and Draft to be my favorites - the Ten One Pogo stylus is awesome for drawing on an iPad, by the way. This is of less importance, of course - what matters is knowing when to sketch, when to stop and where to go next.

Wireframing

The wireframe is a two-headed beast: the low production cost lets you quickly visualize details a simple sketch cannot provide, especially when mocking up interactions and how a user flows through the application. But the quick and cheap affordances of wireframing also provide an invite for features to creep in through the backdoor.

The sheer breadth of readymade widgets, UI components ¹ and even entire frameworks ² for apps like OmniGraffle, makes it painless to drag in a button here and a few tabs there (most often by request from stakeholders) – and before you know it, the budget is blown implementing all these things.

Such a souped-up wireframe will ultimately take on spec-like characteristics; everything in the wireframe is expected to be implemented. More often than not, such conditions are a root cause of an agile process turned waterfall.

Still, apps like Omnigraffle or Balsamiq Mockups have no match when you need an easy way to visualize dynamic/JavaScript-driven interaction, eg. modal boxes, filling out forms, etc. – sometimes it pays to hold back on coding and explore a bit more by wireframing. The cost of trying out another idea is usually much lower in a wireframe, compared to a full-blown prototype in code.

Similarly, you may find yourself wanting to elaborate on a sketch, and need greater detail prior to moving into code and/or visuals. This is often the case when starting work on entirely new products, or large features, with no foundation to build upon and/or concepts that have yet to be fully understood.

The challenge obviously lies in striking the balance. Wireframes can and will often end up in too high fidelity - time wasted on details that would’ve been better spent on a real prototype in code.

Graffletopia has an amazing collection of stencils for Omnigraffle
Yahoo! maintains a library of design patterns in a wide array of formats.

Photoshop

Over time, Photoshop has (d)evolved into little more than a necessary evil to me – it’s a slow, bloated piece of software and it was never a good fit for web design.

My biggest issue with Photoshop is, and has always been, the lack of template hierarchy, page states and how nearly everything must be duplicated in order to be re-used. This enforces a focus on form before function, and leads to things like filler text for body copy, near-identical .psd’s with different filenames, etc.

As much as I try to avoid Photoshop, I feel that the necessary 20% of my time spent using it accounts for 80% of the waste in my process. Sure, this can be alleviated to some extent by applying some best practices like sensible layer names, grouping, etc. – but there’s just no way around the fact that simple changes quickly turn into huge tasks in your average .psd and this has always frustrated me.

I really only use PS for two things these days: rendering graphics that isn’t feasible to do in HTML/CSS, and for quickly altering the layout/dimensions of many screen elements at once.

My approach to mocking up a page is somewhat backwards – where others might do most, or all, of their work in PS, I much prefer to mark up & style as much as possible, grab a screenshot and then move into PS. This remains the easiest way to try out broad changes to the layout and general look & feel. Whenever you need to do excessive search/replacing in the code to try an idea, Photoshop is most likely an easier way to test it.

(Seeing how CSS preprocessing is proliferating these days, such global code changes are becoming less of a hassle with the advent of code re-use in stylesheets. That might prove to be another nail in the coffin for PS as an app for web design – more on that in a future post.)

HTML/CSS

Time spent mocking up a full page in Photoshop or wireframes can rarely be justified these days. Considering how many screen sizes we need to design for, I think we owe it to our stakeholders - and ourselves - to explore solutions in the natural habitat of web design, as early as possible.

I’m a big fan of designing in the browser for a number of reasons. For one, my assumptions about the UI instantly become tangible in a browser: real code, real issues. How should the app respond to a click, a form submission, etc.? These things become much more obvious when you can actually interact with the system, and not just a static representation of it.

There are limits to this approach, of course. Designing in the browser can also be a wasteful part of the process. As a rule of thumb, you should have a rough sketch to work from when you start coding. Whether the sketch is on paper, a wireframe or a .psd is not important - visualizing the concept you’re implementing is what matters.

When you start building your prototype, being sloppy is a Good Thing. Crank out the HTML you need as fast as possible, keep the CSS inline and mostly concerned with structure - dimensions and floats/positioning. Once you’ve got the basic elements laid out, you can start making decisions about how the page or component will fulfill its job and start honing in on a solution to the problem.

You want to keep the code & visuals in a state that allows rapid changes in the early phase of your prototype build. This is why inline styles make sense in the beginning; a component is self-contained, can easily be moved and most importantly – quickly discarded, without any need for removing references to it in other files. Javascript functionality is best avoided early on - you don’t want to get sucked up in some weird programming problem (and you will) when you’re just exploring solutions.

The goal is to expend as little effort as possible to gain the insights you need to inform your decisions. Once you can commit to a solution, you can start to clean up your beautiful mess - this should mostly be a matter of extracting CSS to separate files, and maybe reconsidering the HTML tags you’ve used. For example, you might have marked up an unordered list (<ul>) that turned out to have an implicit order, thus an ordered list (<ol>) is a better fit. This is called code refactoring.

So, which method is the right one?

The approach you take should be proportional to the amount of confidence in your solution and your understanding of the problem space. We’ve all tried spending too much time fiddling with a Photoshop canvas, when we should’ve been drawing lines on paper. Or reworked some code snippet a million times over, when we should’ve been using some simple dummies in a wireframe.

I hope this has provoked some thoughts about your own design process and which methods you employ at a given phase.

If you want to observe a master at work, who makes all of this seem easy, I highly suggest watching Ryan Singer’s two-part Play by Play videos from PeepCode. That session was a large inspiration to this post.

Share your thoughts in the comments, on twitter or anywhere else you feel like it.

Related reading
Responsive Design Warrants a Change in Workflow — Gary Bacon
The Post-PSD Era — Brad Frost