Advertising is it part of your business model?
As long as there is no solution to online advertising compatible with the responsive, using existing ones in a responsive bring you a few headaches techniques. Fortunately, this is a known problem, and solutions are being developed. The article by Mark Boulton "Responsive Advertising" is a very good starting point to study the subject in more depth.
The butterfly effect!
Many of your major problems with responsive project will redefine the roles among the project team. Overall, you have a designer usually focused on functional wireframes and did not have much to worry about important technical constraints, and the other, an integrator HTML / CSS / JS, which could transform the design of your dreams static pages accessible with interaction with onions! These two people did not really need the talents of the other to advance their share of the work.
Roughly, you have the famous sequence: specifications - design - design - Integration - Development back-end, and all the little bits before, after, and in the middle. Each of these steps could be achieved independently. For example, the integrator could very well work on models several weeks after conception.
The responsive design imposes technical heavier than usual constraints on the design, which shakes the very old model. You can not produce a single wireframe fixed as before and you expect the rest of the interaction can be built from it. And you can not expect a web designer functional accustomed to "fix" it produces a result technically relevant, it does not have sound technical knowledge enabling it to meet the flow between the different versions of HTML responsive.
So, you'll have to ask your integrator to make wireframes? Or wait, maybe you can ask your graphic designer to HTML / CSS directly? Aaaah, migraine!
One thing is certain: the separation of roles and expertise in a project team is not as clear as it was, and a good old ax "ok go, we'll make responsive!" not suffice. Must be redefined to the order in which the various stages of a project to be realized.
The head before the legs a little planning
Before you embark on your wireframes, ask yourself some conceptual issues that define how the rest of the operations take place, and how it will be split between the various teams. Once you put it all flat (and, more importantly, you will have confirmed with the client), you will have a solid foundation on which to iterate.
Where are the breakpoints of the design?
As a first step, think the break points of your site: those where the design and layout must change. Decide now will make all the following tasks far more simple (design, graphic design, and, of course, HTML integration).
There are several approaches to take the pragmatic decision, but generally, the choice is between:
content choice: you look at your design with your true final content, and you set empirically where the layout needs to be changed before your aesthetically header overflowing, your column would explode, or your content not simply spring from her! This choice of break points is independent of the target medium. If the website does not have a lot of templates, and each template, the content is not so different from one page to another, it is very appropriate to use this method. This is a simple approach in many ways - there is not no need mediaquery for each type of display stand, since the breakpoints work whatever the size of your screen. However, this approach is not very effective for sites that have a lot of templates, and which, for each template, the content is not at all similar to one page to another (which represents a large many projects, you will know!)
Terminals choice: the choice may be easier looking at the list of devices you want to support, and applying breakpoints on their dimensions. So you follow the resolutions of the most common terminal (or better yet, why not consider what resolutions your target uses, if you can?), And apply them to your designs. This is a much simpler way to complex sites with content not known in advance, but it is also more limited as to the purpose of supporting uniformly a wide variety of screen sizes, etc..
It may be that you were disappointed that there is no more logical to make this decision, but ultimately, it is first and foremost here to take the "best" so that everyone can run in this task! Once the decision is made, the team can move forward ...
Will it fluid across the width?
A responsive design perfect fluid is supposed to be whatever the screen width! That said, real project, a website is made for target as "all smartphones, screen resolution of 1024 px or more, and the iPad" (which is a fairly typical target in 2012). For these cases, a possible compromise is to start on a fixed version for large screens, a fixed version for the iPad, and a version for smartphones fluid. All this fits perfectly with the target, and cost a lot less than going on the fluidity whatever the screen size, including extra-large screens that can be found today! And being pragmatic, the other screens and tablet computers, the result may be not 100% perfect, but it will be suitably adapted and very usable (although it is always a good test for s' sure)
Mobile first or not?
An ideal way to do wrong responsive design is to produce a dense layout for a desktop version, then try to compress everything and "go to" for narrower screens! This does not mean that start with the desktop is a bad idea, and it certainly does not necessarily need to start prototyping your mobile version, but you should ask this question in the context of each project.
Adapt a desktop version in mobile can give you a great boost to innovate and find new ways to reorganize your content. And opposite, starting with the mobile can help you focus on the basic features and get rid of what is not essential for your user. Both methods have advantages decisive!
There is also a third way also acceptable and can match your project according to your budget: to build all versions simultaneously. In all cases, it is always advisable to define in advance the approach you choose for your project, starting with the study of your target and your strategy.
Today, a great way to track what you do it wrong, is to compare a website wireframe for the site with the desktop or mobile application, exactly as Luke Wroblewski has done with Southwest Airlines in his book Mobile first. With a site so dense, it can be very constructive to worry about your foremost mobile user to obtain the interface as simple and streamlined as possible.
By cons, if your target client instead of desktop users to its website, and is interested in delivering responsive for an accessible version of its mobile users, then it is probably more relevant to worry about before all of your users desktop.
What wireframing tool should we use?
The tools for wireframing responsive without requiring a certain amount of HTML / CSS (and thus sufficiently advanced technical knowledge) simply do not exist to this day! The excellent Gridpack App Erskine Design is a beginning, because it creates a responsive grid quickly to test your content, but it is not relevant to the phases of ergonomics as it needs to have now the hands in the code. Ideally, we would need something like Axure or Balsamiq, but fluid version.
In the meantime, you can still use your favorite tool dedicated to fixed widths, and use it intelligently responsive to each version.
It takes action! A few tips ...
You are now ready and have all the weapons in hand to get you started! But if you are accustomed to fixed wireframes, the task will not be easy either! It may be that you aboutissiez a very high number of wireframes for a complete site, but you can to choose is to ignore some of them, and let the intelligent interpretation of what is missing to the integrator.
Also keep in mind some best practices (such as limiting the masking functionality), and do not forget the many technical constraints, especially related to the HTML stream.
To date, there is no universal solution to the design process responsive, so whatever you decide, you'll need plenty of pragmatism in relation to your specific context. That said, there are some common starting points that can influence the definition of your own methodology.
A large amount of short iterations
Ethan Marcotte recommends that consists of a series of short iterations (eg, one week) during which everyone works and shares its findings with the rest of the team. In this way, designers can help developers to improve their work in small design, and vice versa. Although this technique seems logical, and should give you a very balanced result between technology and design, it also requires very restrictive deadlines, and a potentially large budget!
All versions first!
Whichever version you first realize (mobile, desktop, ...), you will always meet your difficulties responsive when you try to fit the remaining resolutions. A way to have a continuous view of the three versions is ... compose the same time! Although this approach is faster and requires less involved in the project, it will require you to have a "designer responsive", that is to say someone who has expertise in achieving a storyboard functional, but that also includes and responsive technical constraints related to HTML stream. And of course, such a profile is not readily available ...
How to make your own "designer responsive!"
A simple way to solve this problem is to bring together a webdesigner "classic" and an integrator for each step, whether design or development. Obviously, this approach is expensive at first, but after a few responsive projects, your designer will be aware of the rules of the HTML stream, and will progressively require the assistance of the integrator. It is an investment constructive, you just create your "designer responsive!"
Validation "in case" ...
For designs and templates complex, an effective way to ensure that all design is technically acceptable is to validate all iterations wireframe with a phase verification technique, where the integrator realizes the wireframe as HTML / CSS. Of course, this step also costs an additional load on the phases of design, but it will ensure with certainty that this whole phase is valid. In addition, it is well done, a majority of this code will be reusable integrations finals, to be performed after graphic design, so all is not lost!
Conclusion
By reading the blogs here and there, you quickly realize that recent attempts to fix a design process are still very experimental responsive: there are almost as many proposals as blogs! Obviously, progress is made, and very interesting proposals have been put forward, but nothing is set in stone.
Knowing this, most at the moment is to make sure to ask the right questions at the start of each project, to make choices based on context, and to engage in its own experiment with a maximum of pragmatism.
And most importantly: if in your experiments, you find new ideas to make these challenges easier to manage responsive, write about it! Share your discoveries with the world, and discover all the ways to improve our work processes!
