Experimenting a different design process for a responsive project.
You might have heard that Responsive Design is changing the way of we produce websites, as a Designer I felt very difficult to work on Responsive projects due to the lack of best practices and tools. For my latest design project I had the opportunity to change of design approach, making half of my design in Html / Css. But working differently was not easy because it depends on other people's workflow. To start I'll talk about designing in code: how to do that, does it take more time? Then I'll highlight the dependencies between my workflow and the Developer's / Producer's workflow.
– I started first with the traditional desktop comp in Photoshop. Creating a nice design means a lot of experiments in Photoshop which stays my favourite tool for exploring different design routes quickly. Nevertheless we know that creating all comps in Photoshop is not the solution because designing a set of static sizes can't represent all many different states of a fluid layout. When the design was good enough, I left the image editor for the code editor to start what I call a, "Layout Prototype". I like to use the Neat Css framework because it's easy to adjust the visual grid from your Photoshop comp inside the html page. Neat is a Sass extension, it able us to write Css in a simpler way.
– Whatever we choose to learn it doesn't change the problem: we have to start learning something that improve our workflow for Responsive Design. Some amazing design tools are emerging: Edge Reflow, Froont or Webflow, they are in-browser visual tools based on Html/Css that's why Designers will have to learn basic Html/Css to fully understand them. I personally prefer to work straightaway in code, it gives me full control of all layout elements.
Initial Layout v1 Layout Updates v2 Animations added v3 Live Version
– During some previous responsive projects I felt the communication between Designers and Developers much harder. Surely designing a responsive layout is like making a moving picture: it's a page with many different states. How do we explain such a complex thing to someone? Designing a set of static screens in Photoshop takes a way too much time for the Designer. Consequently with a Html/Css prototype it is easier to communicate the right informations to the Developer.
– Nevertheless, during the production phase some significant differences appeared between the prototype and the real development work so I still needed to give design feedbacks. It is surprising to notice that on responsive design projects there is always a load more feedbacks to communicate. In consequence I wanted to sit down with the Developer to make all amends directly. Unfortunately, our Producer was not happy with that: to accurately manage time and budget Producers need to assign task to others. That's why we use an Issue Tracker like Basecamp or Jira.
– I previously observed that having to commit all feedbacks in Jira took me so much time, I end up writing endless notes in Pdf like: "too small", "more on the left"… Which isn't precise enough for the developer. I was looking for a solution that could consider the Producer's requirements and after wondering a while, I found something interesting: I call that, "Amending in the Browser" most of design feedbacks are simple adjustments on margin, padding, line height, font size, breakpoints. I could get the perfect layout by changing the Css directly in Firebug, then I used a plug-in called FireDiff to capture which Css properties I amended. At the end I used the issue tracker to upload screenshot of the new layout and the amended Css: the Producer was happy and the Developer knew exactly what to do.
Even with new design tools coming, it feels more and more indispensable for Designers to know the basic of coding. The harder thing on a responsive design project is to communicate informations to others: it would be much more efficient to use the same language and best practices between Designers and Developers to work seamlessly from prototypes to final products.