A future friendly workflow

Picture this situation:

• A client contacts you with a new project and a list of features they “need”.

• You send them a proposal showing how you’ll implement each feature and how much it will cost.

• When the client approves the work, you set up a meeting and go through what they would like the site to look like.

• You then go away for a while and design up some mock-ups. You are still waiting on some content from the client, so you fill in the blanks with Lorem ipsum.

• After receiving the initial mock-ups, the client has a list of changes that include changing colours and copy. Because of this the layout needs to change too.

• This goes back and forth for a while until everyone is OK with the result, but not happy.

• It then goes into development, new features might be asked for during this time, thus resulting in some design hacks.

• Once finished, the project is over budget, you aren’t happy with the end result, but the client got what they “wanted”.

• A month later the client has a new feature that “has” to be added to the site that wasn’t anticipated, and the forum that was a “must have” has no posts or visitors. Oh, and now they want the site to look good on their iPhone.

Sound familiar? I hope not. But this is how a lot of people have been working on the web for some time. Recently though there has been enough disruption in our industry to finally cause even the most mediocre of web designers to rethink their workflows.

The cause of this is, I’m sure you’re aware, the coming zombie apocalypse of small, cheap devices, and more specifically, a growing interest in responsive design.

Because of this I’ve been focusing a lot on workflow (as have many others). But to ensure we don’t get stuck in another workflow rut, we must first adjust our thinking.

Becoming future friendly

My revelation came back in September 2011, when a talented group of people came together to form some ideas, not about responsive design, but becoming "Future Friendly”. What they came up with was not a list of specific techniques that would have to be updated every time the web changed, but a way of thinking to help us adapt as the web changes, or as I like to think, “roll with the punches”.

So what are these ideas? While a more in depth answer can be found on futurefriend.ly, here is a quick summary of the thinking:

• Laser focus: create meaningful content and services.

• Orbit around data: create data that is interoperable, with multiple forms of access.

• Universal content: think about how your data is structured and stored. It needs to go anywhere.

• Unknown vessel, identify: rather than reacting to a specific device, classify device types which take into account future devices.

• Command your fleet: don’t target specific devices, but device capabilities.

This kind of thinking really helped me move from being a print designer on the web, to a true web designer. Once we shift the paradigm in which we think about designing for the web, the list of problems we need to solve becomes evident.

Future Friendly in practise

By taking our problems and thinking about them from a Future Friendly perspective, we begin to find solutions that may not have been apparent before. Let's tackle one of the problems from our situation above.

Endless iterations of mockups

This has got to be one of the biggest problems we face in multi-device workflow. I have scrapped mock-ups for a more iterative and thoughtful process, and it starts with content.

By improving how our content is structured we not only make it more portable, but we also help the user flow. After working out the different screens needed for a site (blog, blog post, event and so on), we work out each screen's purpose, its calls to action and its primary, secondary and tertiary content.

We can now break the content down even further; what types of content do we have and what data can we extract. One type of content may be an event. Each event could contain a date, time, location, title and description, just to name a few. We can store and markup each bit of data in a way that gives it multiple purposes across different devices. Look back at your goals. How could this data improve your user experience? Once we have broken our content down to it’s smallest and most flexible form we can start to adapt it to different use cases.

Once we understand our content we can start to lay it out in code, as basic boxes that represent chunks of content. This is a very minimal living wireframe that gives your team and client an idea of how the content is going to adapt to different device classes. The client can then sign off on the layout of the site separate from the design atmosphere.

Each of these chunks of content usually represent some kind of pattern that is used in multiple places across a site, so identify the common patterns. These patterns are what we can design around. By picking one, say the main menu, and sketching out ideas of how it will work at different sizes, we can come up with solutions we may not have thought of if it were part of a mockup.

We can take some of our sketches and start to play around with them in Photoshop or the browser. When we are happy with the results, we can put some of the patterns into style tiles, along with other elements that convey the atmosphere of the site. There’s another separate sign-off.

From here we can combine the wireframes with the style tiles and start to develop a prototype. Any patterns that aren’t created in the prototype can be added to a style guide. This process involves the client more often and saves the big reveal. They feel like they have had more of a say into the design of their site, and they start to understand how the web really is different than print.

What problems can you solve?

This solution is just one of many that can be found by adopting a Future Friendly way of thinking. Let's remember not to get bogged down in a specific solution, but think differently about every new project. If you find a new solution that worked for you, share it with others - we’re all stumbling through this together.