Process Cards, Version 1

The Year is 2011…

…six months after Ethan Marcotte published his article on “A List Apart” coining the term “Responsive Web Design.” With the eventual adoption of these techniques, layouts were expected to become fluid and flex to multiple device sizes. Content and structure had to be planned and art directed on multiple levels as words like “breakpoints” and “content choreography” entered our conversations.

Inspiration

I was in graduate school after the original iPhone was introduced. I had been a front-end designer + developer for about 4 years at that point and had been following a fairly standard process: discover, content, comp, develop, deploy. At that time, “responsive design” still wasn’t a thing, but there was a clear sense that the way we were designing and developing products had to change.

This thought later inspired my own graduate thesis. It discussed the need for future designers to adapt and think instead of designing full systems and experiences for users. That is to say: designers who had previously been more concerned with UI and aesthetics (or even print) would have to embrace a human-centered process of design that touched on multiple device form factors.

Problem

If a designer had been creating desktop-only products OR was exclusively working in print a transition might be difficult.  If you’d been working in one medium for a long time, change is a pain, right? With that in mind, I decided to make the visual portion of my thesis a deck of cards.

Solution: Process Cards

This deck of cards would guide designers through a basic, linear process, with emphasis on human-centered and responsive design. It would help facilitate thinking through multiple dimensions…multiple types of devices.

So…how do they work?

Easy. We take a standard process and break it up into five distinct Layers:

1. Goals and Objectives: Initial planning and research.
2. Requirements: Technical, content, and visual requirements.
3. Information Architecture: Standard IA and planning…content gathering and analysis.
4. Structure: The visual scaffolding of the project: sitemapping and wireframing.
5. Visual Design: Aesthetics, typography, image usage, etc.

Each of these Layers contains a series of numbered Core cards that are placed in order. Each card presents a single issue for the designer to consider. For example, Layer 1 contains cards titled “Perception,” “Goals,” “Environment,” etc.

Choose

At the end of Layer 1, players are asked to choose which devices they will be designing for. Based on that, they will insert the applicable “smartphone” or “tablet” etc. cards they need under the Core cards.  So for example, if you were designing an app for a small iOS device, you’d pick out and use the cards marked Core (which contain general considerations) and stack the cards labeled Smartphone cards under them.

Users would work through a process with considerations based directly on their device form-factors.

“The Ripple Effect”

Things inevitably change in every project. Decisions get made, requirements get added or removed…committees make insane choices…you know the drill.  On the bottom of most cards are a series of color-coded numbers. These numbers correspond to the later cards that its change would affect. I call this “The Ripple Effect”

For example, in Layer 1, any change to “Perception” would affect: “Content Requirements,” “Visual Requirements,” “Typography,” and a few other cards.  Those, in turn, might affect other cards as the change ripples outward and alters the dynamics of your project.

As a side-note, I think this could be a handy way to illustrate the scope of seemingly minor design changes, to non-designer stakeholders and committees 🙂

Future Revisions

Full disclosure: these cards were dreamed up in 2011. A lot has happened since then.  Some things I’d like to change or improve on for version 2.0:

• Cater to general form-factors instead of device types: We have device classes that didn’t exist in 2011. Large phones, tiny phones, tablets, phablets, watches, fridges…you get the idea. It’s silly to think this way because there are now too many types to consider. It would be more helpful to think in terms of general sizes (tiny, small, medium, etc.) instead of actual devices. We already do it with breakpoint names in front-end dev…why not do this with the cards?
• More emphasis on human-centered considerations: More research and usability studies exist now. Why not use them?
• Remove numbering (somehow): I realize this would make pairing up Core and Device-type cards difficult, it would give designers more flexibility in planning out their own unique processes.
• Visualizations: Cards that discuss real deliverables (sitemaps, wireframes) could benefit from visuals, instead of words. Just saying.