Where I work, we have 11 Designers/Front End Developers who work together in the User Experience arm of the company. We’ve been aware that Responsive Web Design is an important concept to grasp in order to meet the needs of our customers. In fact, we discussed it during my interview before they hired me last summer! Responsive Web Design is not the sole means by which our company is addressing the needs of users outside of the desktop environment, but we have decided to make it a part of our baseline structure. We think it is that important.
We are at a time in web development that is growing faster than we could imagine. We can access the web from almost anything these days: phones, televisions, game consoles, cars, refrigerators, printers. You name it. We already knew that “mobile” was important as more and more users access web services from whatever device is most convenient for them at the time, but we can’t predict what the future has in store for us. We can’t be certain what next big thing will disrupt our comfort zone and have us scrambling to support it.
While being in full agreement as a team that we have to conceptualize our product “Mobile First”, making the switch wasn’t that easy. We’ve employed the classic method: Designers do a great deal of layout and branding manipulation in Photoshop until the comp is stamped with final approval. Then, that comp gets handed over to the “Realizers” (a.k.a. Front End Developers) to become a working interface that matched the comp. The hurdle we faced was how to change that workflow to fit with new, flexible schemes to cover a wide range of devices. We had to come up with a workflow that allowed for a lot of collaboration, while not hindering forward progress. We realized that it was such a big shift in thinking and process — overwhelming, even — that we seemed almost paralyzed as to where to begin.
Baby steps are good steps
For the past year, we’ve been adjusting our own internal mental models away from desktop centric design to something less specific — something more open to adjustments as needed. We’ve struggled at times, but I credit us with having taken baby steps to move a behemoth of a product like ours into a more future friendly product. The first step was to take the desktop centric version that was already in production and adapt it to be more “responsive“. That meant picking some set of breakpoints and adapting the layout to work in those parameters, while having enough flexibility to adjust gracefully between the breakpoints we had set. We knew this wasn’t the ideal solution for our product overall, but it was certainly better than nothing! It was also better than holding off until some future redesign that may or may not make it onto our roadmap before addressing the need. The effort paid off, too! Once it was revealed to the rest of the Product Development arm of the company, they were thrilled with the results. So much so, that Responsive Web Design was something that was considered with every project moving forward; but it was the kind that had just been implemented – the “Desktop to Mobile” conversion type. My UX comprades were still itching to shift things around, so that small screen design would be where we began our efforts, adjusting the designs as more screen space became available. We were still scratching our heads about how to get started down that road with a team our size. Enter Breaking Development…
I was fortunate enough to hear Stephen Hay (@stephenhay) present his process in Orlando, FL in April. When I saw and heard what he had to say, I had an “Aha!” moment. It felt like his workflow might be a really good jumping off point for our group. It may not be exactly what we need, but the only way we would find out is to try it and then make whatever alterations we need for it to feel natural to us. I shared my excitement with some people around the office. You know, the usual conference high when you hear some stuff that blows your mind or makes you realize you have a path forward from a place where you felt stuck… Duing a 1:1 meeting with my boss, she encouraged me to get us moving in the right direction based on what I learned at the conference, so I did what any sane person would do: I ripped off everything Stephen said, giving him full credit naturally, and compared it against our current process. Only the first 2 steps of our current process would remain unscathed and become part of our Responsive Workflow; they covered what is known as “discovery”. Our discovery process was pretty solid, given our circumstances.
My starting point for outlining our Responsive Workflow came from slide #34 of Stephen’s presentation. I took a page from one of our products and rethought how it could be presented using the 10 steps he outlined, which are:
- Content inventory
- Content reference wireframes
- Design in text (structured content)
- Linear design
- Breakpoint graph
- Design for various breakpoints
- HTML design prototype
- Present prototype screenshots
- Present prototype after revision
- Document for production
While walking through the steps, I started to feel that considerations for branding in our products need to be represented in this flow, as it wasn’t really clear how that part would fit in. Those on our team who are stronger in this area will need a way to provide visuals to incorporate into our final products without having to provide full comps for every permutation of the layout. I thought that Style Tiles might be a good fit here, since they provide strong visual cues without prescribing layout. Additional design solutions and graphic elements will work themselves into the HTML design prototype as the team collaborates.
After my initial comparison of Stephen’s process to what our process could look like, I presented my version of a Responsive Workflow to our group last week. Here are the 10 steps I suggested as our starting point:
My Suggested Workflow
- Research product or buyer’s needs
- Determine necessary features
- Determine feature hierarchy
- Design in text (HTML); content out (linear flow)
- Generate a breakpoint graph
- Design (sketch?) for various breakpoints
- Design style tiles
- HTML prototype (periodic code reviews)
- Present prototype screenshots
- Generate style guide
The first two items on the list are part of our “discovery process” as I mentioned earlier. The third step, “Determine feature hierarchy,” is where our new process begins. Our UX team has already determined 2 exercises to test this process on internally, so that we could dive in and get a feel for it. I am really proud that our team isn’t just talking about this. We’re actually doing it!
Sharing what we learn
I plan to write what we learn as we go through this workflow transition. The reason I want to share this is because I firmly believe we are all learning how to function in an increasingly “responsive” web. I don’t expect that what we end up with will be “the one true way” a responsive workflow benefits a team. What I hope to reveal is how to start with someone else’s process and adapt from there to suit your own needs, whether you work on a team or as a one person show.