Responsive Process. We all have one, or have an idea of how we envisage a responsive project running. Whether it is within an agency environment, or as a freelancer.
I, for one, fall into the former. My specialty is front-end development and I lead a team to do just this. So when I read articles, or see talks from industry leaders about responsive process, I can (most of the time) only take them onboard with a pinch of salt.
This isn’t because I disagree with their methods, ideas or opinions. It’s down to the fact that the practical application often only works in a set up where the designer also codes.
Adam Onishi raised the question the other day about designers who hand their designs over to developers, and what this entailed for them. Whether there is consistency amongst this workflow in the industry, or what we could do to improve.
Responsive Web Design is one of those moving goalposts depending on who you speak to. How much involvement do the designers need? How much or little do they physically design in Photoshop?
UX to Design to Build
At the agency I work at, we have specialists and departments in each field; UX, Creative and UI being the key stakeholders in any responsive project.
Before any development of the project is completed, we go through two phases of delivery: wireframes and design. In both parts, a single mobile and a single desktop view are considered by each department and then handed over to the UI team to build.
Whilst as developers we appreciate that responsive is so much more than just these two views, I find it ensures that hierarchy and aesthetics are considered for the two extremes by the respective specialists. It is then our jobs to, and one that I most enjoy about a responsive project, fill in the gaps.
By approaching projects this way, we can ensure that the integrity of the design and user experience is maintained, but without the overhead of a mock-up of every possible device resolution being created.
Communication throughout the process
This approach does suggest a level of isolation between the respective fields, but I cannot stress the importance of communication enough.
Constant conversations with each other, questioning and evolving ideas is pivotal to creating a successful user interface – regardless of whether the project is responsive or not. Ensuring that no assumptions are made, and that people understand the aspects of what is going to be authored and how these are going to work from a multi-platform, multi-device perspective.
Book in review points, share progress around a colleague’s device – the language of responsive is still relatively new, and showing people is a very good way of supporting your explanation and vision.
Communication does not stop just at your internal teams. Explain your process and talk through results with your client – leaving them in the dark until the end will only lead to unexpected surprises, pains and confusion.
Laura Kalbag wrote an interesting article recently on Browser Windows and Responsive Language, which might aid in your communication both with internal teams and your clients.
Is there another, better way?
I am all for listening to other people’s processes and opinions. Whilst this is my take on a responsive process – I would encourage people to share theirs. It would be interesting to see how other people’s process differ in a similar set-up. Or how we as an industry can improve.