Responsive Principles: More Than Designing for Size

I have been giving a lot of presentations this year, trying to spread the word on what I perceive as good design or process principles. My next one will be at the Float Mobile Learning Symposium at the end of the month. I presented here last year and it was an unusually interesting and well-informed group of presenters, as well as a very well-run event.

I think of presentations, or blog entries, in much the same way I consider taking notes in a class or while watching a presentation. The very act of writing down your thoughts or perceptions causes you to evaluate, and codify them, and come up with new relationships and better information. Actually, my design process as a whole is built on principles like this as well.

Every presentation I give, even if broadly speaking to the same topic, is custom built. Not just to give you the most bang for your buck, but because I can't stop myself. Simply practicing the presentation reminds me of dozens of things I need to revise, or a new direction to take it. Going to conferences just makes it worse, as I see how many other presentations are related, and my brain starts spinning. Oh, if only I could be assured of the absolute truth of my ideals and just keep saying the same thing in blissful ignorance.

Lately, I've been talking about a few basic topics:

• Always, design for every screen 
• Lately, really using your device capablities 
• As well as some thoughts on integrating development and UX processes

A few weeks ago, especially, when I was at D2WC, these threads started coming together, and tying into others I saw at MoDevUX, and other events, and twitter streams. Especially around how responsive design is practiced, how it should work, and a lot of multi-platform topics I suddenly realized are all the same topic really.

I am still working out the details, but this is what I am going to be talking about at the Float event in a few weeks.

Responsive Design

Responsive design is not new. Which is great, because we can use these decade-old principles instead of inventing new ones.

But the way it is preached and practiced, as client-side, and all about scale, is misguided and serves no one very well.

Also, responsive design should not (usually) be responsive development. The full embrace that the new Dreamweaver, for example, puts on RWD is bad.

RESS & device detection

RESS is only a little better as typically discussed, but it very much gets us on the right track. Device detection means we can start reacting to the device more directly.

More than scale

Which means, leveraging platform capabilities. This is where mobile starts getting better than desktop. Not just because its always around, but because it has sensors, and it has contextual smartness built in. As a simple case, linking to email on a desktop is stupid, as the link usually launches some stupid email client you never use, and is a jarring experience anyway. On mobile, app switching is common, they generally interchange data better, or know the existing context and react appropriately./p>

Design for every platform, then design for each platform

This is exactly where I am going, tying my process of Design for Every Screen to platform capabilities. You design for user needs, corporate goals, data availability, and the overall experience. Then you branch the design to take advantage of the capabilities of each platform, without falling into the web/development process pitfall of feature = page. If a feature can be met by an email, or another app, or offline processing, or a sticker on the box, then that is just as valid a solution to the user's problems.

Implement for every platform

Implementation is a key part of this, but I hesitate to say "development." It's best to raise that up a level, and discuss how the product will be built, hosted, released and maintained in the same breath as how it is marketed, sold and paid for.

So, how do you implement this for multiple platforms if not "responsively"? Well, "correctly." Start by implementing the services, datastores and writing business rules that can be used everywhere. Layered development can be hugely efficient here, so pull as much software off the presentation layer as possible. Then build the presentation of individual platform codebases that take advantage of not just the UI and interaction differences, but the available tools and processes of the platform.

Operationalize the process to change the culture

This is truly holistic design, and only can emerge with collaboration from the process level on down. More importantly, I think this is something hard to impose on a team with process, and begins to be a discussion of creating a design culture (as part of the "how do we become Apple" discussions).

I tend to say you can get there by operationalizing processes that assume this level of consideration. Don't just impose better design, but try to make some of these steps core to the practice. Add them to strategy documents, and so on. When they get performed routinely, they then become performed as second nature, and are baked into the culture.

Keep your goals and principles in mind

You cannot get that cultural change tomorrow, but there are tactics you can employ to improve outcomes. You did, of course, figure out the audience who will use the product, their needs and the company's goals, right? I try to always make design principles to make these directly executable and something each design element can be checked against.

Yes, you can change them over time when more information comes in, but you never set them aside. And by "never" I mean they must be considered not as project principles, but program principles. When the next release happens, these same goals have to be retained. That will lead to answers of how you preserve first-release features, how you expand to other platforms, and even the timing of releases with different platform processes and pressures.

So, what do you think? Really, I will be tweaking this until the day I present it, so if there's something I seem to have missed, or which is unclear, tell me about it and I'll agonize over it as well.

And of course be sure to join me in Chicago on the 25th.