Adapting to a Responsive Design Workflow
At work, I've had the opportunity to dive deep into responsive design for a full refresh of a banking site. That process has taught me much about adapting to a responsive-friendly workflow. Now I want to apply that first-hand experience, plus insights from people like Trent Walton, Brad Frost, Luke W, Jason Weaver, and numerous others.
Working with very large organizations has reinforced my belief that excess documentation add huge amounts of waste to software development. Even in my personal projects, waste creeps in.
Here's how I'm getting leaner:
1. More Sketching, Less Wireframing
Wireframes feel more complete and more authoritative than sketches. Wireframes are often a discrete deliverable, an artifact that's dressed to impress. Wireframes often raise questions that only other documentation can answer.
Documents breed like rabbits. And all those documents have to stay in sync. And the more time you spend creating, editing, and maintaining documents (and having meetings about documents), the less time you spend working on the product.
Sketches suggest impermanance. Sketches inspire critique. Sketches are a conversation tool. You can crumple them up, throw them away, and nobody cares. Sketches keep work moving.
2. More Coding, Less Photoshopping
Designing responsive sites in browser helps you find flaws faster. Mocking up mobile, tablet, desktop, and widescreen views of the same design is the bane of efficiency.
More importantly, working with the medium you are designing helps you understand your medium. And that helps make you a better designer.
Instead of Sketch -> Wireframe -> Mockup -> Code -> Test, Sketch -> Code -> Test.
At first glance, it may appear that I've taken most of the design out of the process. But design isn't a step in the process, design is the process.
Sketching, coding, and testing are the tools to concept, create, and evaluate design.
janainaart
andulkaphoto
vaporwave
germansingergirl
prguitarman