Cloud Four Blog

Technical notes, War stories and anecdotes

Redesigning Ceasefire Oregon

Last fall after the Umpqua Community College shooting in Southern Oregon, I decided that my donations and support for Everytown weren’t enough. I wanted to do more. And I wanted to do something local.

I did some research and discovered a wonderful advocacy group called Ceasefire Oregon. They seemed to be both passionate about sensible gun legislation and also wonky which appealed to me.

Ceasefire Oregon is the best resource on local legislation. Unfortunately, the website was difficult to read and navigate.

Old Ceasefire Oregon Home Page

So we offered to help redesign Ceasefire Oregon on a pro-bono basis. And I’m pleased to announce that the new Ceasefire Oregon site has launched.

Ceasefire Oregon's new site

In addition to the opportunity to contribute to a great cause, we found several pieces of the project interesting from a technical and design perspective.

Rebranding Ceasefire Oregon

The first challenge was finding a way to convey what Ceasefire Oregon does in a logo. The old logo was a riff on a shooting range target which seemed less than ideal for a gun violence prevention group.

Ceasefire Oregon's Old Logo

We talked to Ceasefire Oregon about their goals and what they wanted to convey:

  • Change is possible
  • Empowered
  • Moving ahead
  • New future
  • Action

We collaborated with Ceasefire Oregon on mood boards to get closer to the brand. And then we began working on logo ideas.

Aileen designed an origami-like dove that captured everyone’s imagination. It became the centerpiece of the new design.

Ceasefire Oregon Dove

Once the dove was approved, Aileen began work on variations of the logo. We wanted to support both horizontal and vertical logos as well as different versions for the three different Ceasefire Oregon organizations.

Ceasefire Oregon Education Foundation Logo

Pattern library

After we had the high-level brand details sorted out, we moved immediately into building a pattern library.

Ceasefire Oregon Pattern Library

I want to highlight a couple of things in the pattern library.

First, because of the three different sites and their color schemes, there is a pull down menu in the upper left that allows you to switch which colors are being used. This is most noticeable when looking at buttons, blocks, and navigation.

Second, during development, our pattern libraries rarely follow a completely linear progression from smallest components to larger ones. You can see evidence of this in the sandbox where we experimented with designs.

Local WordPress Development

For many of our recent projects, our clients had well-established content management or ecommerce systems. This has meant that we were able to keep all of our development front-end and exclusively used local development tools.

Ceasefire Oregon needed a new content management system. The old site was running on Drupal 6 which has been discontinued. We decided to move them to WordPress.

We wanted to find a way to continue to work on our own local machines while doing work on a content management system. We ended up running vagrant installs of WordPress.

I also want to give a hearty endorsement to WordPress Migrate DB Pro. We lost a lot of time trying to get open source database syncing solutions to work. I wish we’d bought the plugin earlier.

Pattern Library to WordPress Theme

One of the thornier challenges we ran into was figuring out how to tie the output of the Ceasefire Oregon Pattern Library to the WordPress theme that we were developing.

We ended up with a solution that worked pretty well. The gulp process for the pattern library also created a compressed CSS file that was aliased into the Vagrant environment in the theme directory. Whenever we made changes to the pattern library, they were automatically reflected in our theme.

The biggest downside to this approach was that the repository was a mixture of pattern library and theme code. But this combination sped up our design and development so much that it was worth it.

Content Strategy and Modeling

We spent time working with Ceasefire Oregon on their content strategy. We’ve done a little bit of this in the past, but this was the first time we’ve run workshops with clients discussing content. It is clear that the new site benefits from this work.

I’m particularly proud of how Sara and Gerardo mapped the content into WordPress content types. The new legislation section makes it easy for Ceasefire Oregon to keep track of new and old bills. I expect it to become the canonical source of gun safety legislation relevant to Oregon.

Ceasefire Oregon's New Legislation Section

And much, much more

This article is inadequate for describing all of the hard work that went into this project by everyone on the Cloud Four team. I’m incredibly proud and grateful for everyone’s contributions. It means a great deal to me.

And I hope we get a chance to write in more detail about the way the site was built in the future.

Making Oregon Safer

We’re tremendously grateful and humbled by the work that Penny Okamoto, Joanne Skirving and the rest of the volunteers at Ceasefire Oregon do. If you feel strongly about sensible gun legislation, they deserve your support.

We’re honored to have had the opportunity to work with them and to contribute our small part towards helping make our community safer.

Autofill: What web devs should know, but don’t

Many people know that you can scan your credit credit in Mobile Safari. But how many web developers know how to create a form that supports that feature?

Not many I’d bet.

Photo of someone scanning their credit card

Photo source: Auto-Fill Credit Card Forms Using Your iPhone’s Camera in iOS 8. Used with permission.

It doesn’t help that Apple has provided zero documentation on how the scan credit card feature works.

But there is another factor at play here. The scan credit card feature is a subset of browser functionality that web developers have long ignored: autofill.

It’s understandable why web developers haven’t paid much attention to autofill. When you’re filling out forms with test data on a regular basis, autofill tends to get in the way.

But autofill is an important feature for our users. Google has found that “users complete forms up to 30% faster” when using autofill.

So let’s learn how autofill works, how to build forms that support cross browser autofill, and take advantage of new features like scanning credit cards.

How does autofill work?

Until recently, there were no standards when it came to autofill. Each browser implemented their autofill features differently and there was little documentation on how a browser determines what content a field expects.

Despite this chaotic situation, browsers seem to have settled on two main approaches:

1. Pre-determined autofill fields

Chrome, Opera and Safari have all taken the approach of identifying high-value form fields and providing a way to manage what the browser will autofill for those fields.

Opera Autofill Manager

For example, Opera provides autofill for addresses and credit cards. These can be managed in the preferences as shown above.

Chrome, Opera and Safari all differ on which fields they provide autofill for, but the basic fields needed to complete a checkout process are well supported.

Most users never have to see or edit these preferences in order to utilize autofill. The browser watches the person filling out forms and when it recognizes an address or a credit card, it will ask if the user wants them to save that information to reuse later.

2. Autofill any field

If the previous approach is like a scalpel applied to preselected fields only, this second approach is a chainsaw cutting down every field in view.

When a form is submitted, Microsoft Edge and Firefox will store the value submitted along with the value of the name attribute. If the browser sees a field in the future with a matching name attribute, it will provide autofill options. Firefox also appears to look at the id in addition to the name attribute

Because there are security and privacy concerns with this approach, the autocomplete off value has long been supported to prevent the browser from storing and autofilling sensitive information.

Which approach is better?

While the second approach works for more fields, as a developer, I much prefer the pre-determined autofill fields approach.

It makes it much easier to figure out what information the browser has to autofill. It is also easier to set up test profiles.

Plus, with the second approach, you actually need to submit a form in order for the browser to store values to use with autofill. The browser won’t remember your answers without the form submission.

It also makes me nervous to think that the browser might store credit card information in a non-encrypted way if it can’t clearly identify the type of field.

Given how concerned Microsoft and Mozilla are about security and privacy, I’m certain they’ve put protections in place. But I personally feel more secure looking at an autofill preferences pane and seeing credit card information clearly separated and understood by the browser.

All that said, I don’t know what end users prefer. The second system works in more places, but I’ve seen quite a few support questions where people have been trying to remove their autofill options from the browser history.

It will be interesting to see how Edge and Firefox change when they began to support the new autofill standard.

One behavior to watch for

Sometimes browsers require more than one field of a certain type before they will present you with autofill options.

For example, in the following animated GIF, Safari won’t offer to autofill the single cardholder field, but it will offer to autofill it once there is a second card number field.

Safari Autofill working with two fields, but not working with one field

However, if the only field being collected is the card number, then Safari will offer the autofill option.

My experience has been that creating isolated test cases for single fields can be challenging because of this behavior. At one point in my testing, I encountered Opera requiring three fields before it would autofill, but I can no longer recreate that behavior.

This should never be an issue for a user so long as your form is written to support autofill (more on this soon), but I note it here in case you’re attempting to troubleshoot autofill and encounter this behavior.

The standards-based approach to autofill

Thankfully, there is a way forward for autofill. HTML5 recently expanded the autocomplete attribute to provide hints to the browser about what content a field expects.

The autocomplete attribute has been around for several years. It started with two values: on and off. By default, the autocomplete attribute is set to on which means that the browser is free to store values submitted and to autofill them in the form.

However, some fields are poor candidates for autofill behavior. In that case, the autcomplete attribute can be set to off to tell the browser that this field should be not autofilled.

Recently, additional values have been added as options for the autocomplete attribute. These new options are called autofill detail tokens. These tokens tell the browser what information the field is looking for.

One type of token is called the autofill field names. The autofill field names tell the browser what type of information a field expects.

For example, one of the autofill field names is organization. The HTML5 specification says that organization refers to:

Company name corresponding to the person, address, or contact information in the other fields associated with this field

If you wanted to tell the browser to autofill the organization field, your code would look something like this:

<input type="text" name="foo" id="bar" autocomplete="organization">

The HTML5 specification has a great table listing all 53 possible autofill field names, what their intended use is, and what type of input must be used with it.

That’s autocomplete at its simplest, but it gets more powerful and a bit more complex.

Shipping and billing

The value of the autocomplete attribute is actually a space-separated list of tokens. So for example, if you wanted to collect shipping information, you would prepend the autocomplete value with the “shipping” token like so:

<textarea name="shipping-address" autocomplete="shipping street-address"></textarea>
<input type="text" name="shipping-city" autocomplete="shipping address-level2">
<input type="text" name="shipping-state" autocomplete="shipping address-level1">
<input type="text" name="shipping-country" autocomplete="shipping country-name">
<input type="text" name="shipping-postal-code" autocomplete="shipping postal-code">

The billing token works exactly the same way as shipping.

Telephones, email and instant messaging

Another token option applies to telephone, emails and instant messaging. For those services, there is an optional token to indicate if the autofill field name is referring to home, work, mobile, fax or pager.

For example:

<input type="tel" name="home-phone" autocomplete="home tel">
<input type="tel" name="work-phone" autocomplete="work tel">
<input type="email" name="home-email" autocomplete="home email">
<input type="url" name="chat" autocomplete="home impp">

Broad versus narrow autofill field names

The specification provides for both broad and narrow autofill field names for many of the types of information.

For example, in addition to the tel field which would be a single input containing a full telephone number, there are also:

  • tel-country-code
  • tel-national
  • tel-area-code
  • tel-local
  • tel-local-prefix
  • tel-local-suffix
  • tel-extension

The specification authors encourage you to use the broad autofill field names as often as possible:

Generally, authors are encouraged to use the broader fields rather than the narrower fields, as the narrower fields tend to expose Western biases. For example, while it is common in some Western cultures to have a given name and a family name, in that order (and thus often referred to as a first name and a surname), many cultures put the family name first and the given name second, and many others simply have one name (a mononym). Having a single field is therefore more flexible.

I agree with this recommendation. And as a practical matter, it means that it is important to pay attention to the table of values and make sure you’re using the right one for the field you’re working with.

Sections

The final feature of the new autocomplete attribute tokens is the ability to declare an arbitrary section to group fields.

A section is defined using a token that starts with section-. What comes after the dash is up to you. The specification provides this example of sections:

<fieldset>
<legend>Ship the blue gift to...</legend>
<label> Address:
  <input name="bc" autocomplete="section-blue shipping street-address">
</label>
<label> City:
  <input name="bc" autocomplete="section-blue shipping address-level2">
</label>
<label> Postal Code:
  <input name="bp" autocomplete="section-blue shipping postal-code">
</label>
</fieldset>
 
<fieldset>
<legend>Ship the red gift to...</legend>
<label> Address:
<input name="ra" autocomplete="section-red shipping street-address">
</label>
<label> City:
<input name="rc" autocomplete="section-red shipping address-level2">
</label>
<label> Postal Code:
<input name="rp" autocomplete="section-red shipping postal-code"> </label>
</fieldset>

All the tokens

Put all together, we’ve now got a much more complex set of tokens for the autocomplete attribute. And the order of the tokens matters.

First, you’re either using on and off values OR you’re using autofill field names. You can’t use them at the same time.

If you’re using the autofill tokens, the order is:

[section-](optional) [shipping|billing](optional) [home|work|mobile|fax|pager](optional) [autofill field name]

And keep in mind that [home|work|mobile|fax|pager] only applies for the telephone, email and chat autofill field names.

The longest possible set autofill token might look something like this:

<label for="foo">Mobile phone for delivery</label>
<input type="text" name="foo" id="foo" autocomplete="section-red shipping mobile tel">

Yay for standards! We’re done, right?

I’m afraid not. My hope is that eventually all of the browsers will support the expanded autocomplete standard, but that’s not the current situation.

I tested browsers on mobile and desktop to see what attributes the autofill appeared to honor. This is what I found:

Browse Version OS ID Name Autocomplete
Chrome 50 OS X 10.11.4 No Yes Yes
Opera 35 OS X 10.11.4 No Yes Yes
Firefox 46 OS X 10.11.4 Yes Yes No
Edge 25 Windows 10 No Yes No
Safari 9.1 OS X 10.11.4 Partial Partial Partial
Safari 9 iOS 9.3.1 Partial Partial Partial

Thus far, only Chrome and Opera clearly support the new autocomplete features.

Safari appears to have partial support, but because they don’t have documentation, I can’t tell if this is intentional or simply a regular expression match that happens to be looking at the autocomplete attribute as well as name and other attributes.

Safari’s strange behavior

Since the release of iOS 8’s credit card scanning feature, web developers have been reading tea leaves trying to divine what combination of markup Safari is looking for.

Some suggest that you have to have specific values in the name field. Others found values in ids work. Even labels seem to matter:

The Cardholder’s name is quite a bit more tricky. We messed around with various IDs for a long time and almost gave up. We couldn’t figure out an ID that would cause Card Scan to populate it. After much frustration we finally discovered that the TEXT of the label associated with the field matters. Setting the label text to “Name on card” was the magic trick.

I’ve done quite a bit of testing, and I’m still not confident that I understand fully what Safari is doing. However, I’ve seen enough to be able to draw some basic conclusions:

Contact and address fields support autocomplete

Safari recognizes the form I created that only includes autocomplete attributes. The moment I start typing in the first field, it offers to fill in the form with my contact information.

Safari offering to autofill my contact information on a form that only uses autocomplete attributes.

This all works as expected with a couple of caveats.

First, it is unclear what Safari is using to make decisions about what information to autofill from my contact in the Mac’s address book. My job title is filled in, but the company I work for isn’t.

Second, it doesn’t give users the option to select which information they want to use. My contact contains both my home address and my work address. Safari only wants to autofill my home address. I’m out of luck if I want to ship something to the office.

Payment fields are completely wonky

When it comes to the payment fields, Safari’s behavior changes completely. The autocomplete attribute is ignored.

Instead, there is some sort of magical heuristic that Safari is using. And because I’m not an Apple magician, it has been difficult to discern what Safari is actually doing:

Video of me struggling to figure out why some labels for payment fields work and some fail.

In the video above, I edit the labels of two fields. Both have autocomplete set as well as name and id which should help Safari identify the field.

And yet, Safari doesn’t recognize the fields until the labels are changed to Name on Card and Credit Card Number. As mentioned earlier, Safari needs to see more than one field to trigger autofill.

Then I try changing the label to CCNumber which continues to work. However, changing it to CC Number breaks the autofill.

Basically, Safari has an unpublished list of terms that it is searching for. Fortunately, Jacques Caron was able to extract a list of strings from the iOS Simulator that Safari appears to be looking for:

  • card number
  • cardnumber
  • cardnum
  • ccnum
  • ccnumber
  • cc num
  • creditcardnumber
  • credit card number
  • newcreditcardnumber
  • new credit card
  • creditcardno
  • credit card no
  • card#
  • card #
  • cvc2
  • cvv2
  • ccv2
  • security code
  • card verification
  • name on credit card
  • name on card
  • nameoncard
  • cardholder
  • card holder
  • name des karteninhabers
  • card type
  • cardtype
  • cc type
  • cctype
  • payment type
  • expiration date
  • expirationdate
  • expdate
  • month
  • date m
  • date mo
  • year
  • date y
  • date yr

In my experiments, both:

<input type="text" name="nameoncard">
<input type="text" name="ccnumber">

and:

<label for="foo">Name on Card</label>
<input type="text" id="foo" name="foo">
<label for="bar">Credit Card Number</label>
<input type="text" id="bar" name="bar">

will trigger Safari’s autofill and the scan credit card feature on iOS. However, putting the same values into the autocomplete attribute will not work.

Building a cross browser autofill form

Given what we’ve learned, is it truly possible to build a form that supports autofill across browsers? I think it is.

Or at least, we can get very close by taking these four steps.

1. Add autocomplete attributes

This is the future of autofill. Browsers that don’t recognize the values will ignore them.

This is progressive enhancement at its best.

2. Use common values for input name attributes

To take advantage of autofill for Firefox and Edge users, you have to hope that the values you pick for the name attribute match what developers on other sites have used.

One way to do this would be to survey popular sites and see what they use and then use the same values.

Or perhaps use the same values as the autocomplete field in hopes that as more web developers become familiar with the standard that they will start using those names for their fields.

Unfortunately, there is no way to guarantee that your Firefox and Edge users will have previously visited a form that uses the same name values as your form does.

3. Add name and/or label values that match the list Safari is looking for

Using the list that Jacques Caron was able to extract, you can modify the values for the name attribute or the label to match what Safari expects.

4. Make autofill part of your test plans

Lately, I’ve been asking audiences to raise their hands if autofill is part of their test plans. No one does.

I’ve been working on the web since 1996, and I have yet to see autofill as part of the test plan.

I suspect that autofill is a blindspot for web developers and designers. Therefore, it is critical we test our products to ensure that they work well with autofill.

The final form

Here is a sample form that supports autofill on Chrome, Safari, Opera, Firefox and Edge:

See the Pen Cross Browser Autofill Form — Selected Fields by Jason Grigsby (@grigs) on CodePen.

To see it in action, you’ll need to view it on CodePen under https or the browser won’t fill in the credit card information.

I’ve also built a form with all 53 fields in the autocomplete specification. No browser currently supports all 53 fields.

The future of autofill and forms

There is a lot of movement from browser makers towards tackling the problem of web payments. The Payment Request API is being co-authored by Mozilla, Microsoft, Google and Facebook.

Apple is participating in the Web Payments Working Group which is where the Payment Request API is being hashed out. So it appears that Apple is at least nominally onboard with the Payment Request API.

Plus, rumor has it that Apple Pay will be available on mobile web for the holiday shopping season which makes it feel like this new momentum around web payments might be real this time.

This renewed focus on streamling the web checkout process has me optimistic that support for autofill detail tokens will grow in the near term. And these tokens make creating forms that work with autofill so much simpler.

And most importantly, supporting autofill will make filling out forms less tedious for our users and lead to increased sales for e-commerce sites.

The Power of Responsive Design Sprints

In 2008, I sat gobsmacked in Web 2.0 Expo session. The topic of M. Jackson Wilkinson‘s presentation was “Design and User Experience in the Agile Process“, and I literally couldn’t imagine designing that way.

Fast forward seven years, add responsive design to the mix, and I can no longer imagine designing any other way. Responsive Design Sprints are key to our process.

Why agile for design?

Our path to agile for design started with moving to agile for development. Lyza and Megan spearheaded a move to agile development a few years ago and that change influenced the way we looked at projects.

Because of our success using agile for development, we were primed to try it when responsive design broke our existing design process.

We’ve found that agile design is ideally suited for designing responsive patterns. It allows us to focus on small pieces of a design and iterate on them quickly.

What is a Responsive Design Sprint?

Most of the time when people talk about design sprints, they’re referring to product design sprints. This is the process that Google Ventures, our friends at Fresh Tilled Soil and others have developed and promoted as a way to quickly validate product design and direction.

Thoughtbot's Product Design Sprints diagramThoughtbot’s Product Design Sprint Phases

Product design sprints are an exceptionally useful tool. The phases in our sprints have some similar characteristics—you’ll see parallels to the Understand, Diverge and Prototype phases in particular.

However, Responsive Design Sprints are decidedly different in what they’re trying to accomplish and diverge from Product Design Sprints in some specific ways.

Pre-sprint planning

Our first step when planning a project is to break the site down into the patterns—from the lowest level to higher-level components—that we need to design.

patterns-into-sprints

This is our starting position for each sprint, but because we’re working in an agile fashion, we’re flexible and can change what patterns are being worked on. We can also spend more time on patterns or bring patterns in from later sprints if we’re ahead of our plan.

Before each two-week sprint, we collaborate with our clients to figure out what patterns will be covered in the upcoming sprint. This not only allows us to confirm that our priorities are correct, but it also gives our clients a heads up on what they need to prepare for the sprint kickoff.

Sprint Day 1 — Client briefing and small screen sketching

Client briefing

Each sprint starts with a briefing on the patterns for that sprint. This briefing is led by the client team.

During the briefing, the client team provides everything they know about the patterns including:

  • How the patterns are used.
  • Any edge cases for the patterns.
  • Analytics information on the patterns.
  • User testing that has been done.
  • Support or user feedback on patterns.

If we’re dealing with foundational patterns like typography and buttons, the briefing could simply be going over any existing brand and style guidelines.

However, when we start working on more complex patterns—for example a shopping cart interface—there is often quite a bit of information about the pattern to convey.

Small screen sketching

After the briefing, we start group sketching sessions. Ideally, we do this with our client, but often we work with teams in other parts of the world so we only get to sketch together a couple of times during a project.

Everyone participates in the sketching irrespective of roles. Sketching small screen designs helps people start thinking more tangibly about the constraints of small screens. It is one of the reasons why we include clients in sketching exercises whenever we can.

We pick the portions of the patterns that we think are going to be the most difficult to fit on small screens and sketch those. This often means that we’re not sketching the entire interface or even the entire pattern that we’re looking at, but instead just a small portion of the pattern that looks particularly troublesome.

Sketches on sticky notes

We sketch on small sticky notes using Sharpies. Every sketching session is time-boxed. The constraints on time, size and low fidelity markers prevent people from getting too detailed in their drawings.

And we use Sharpie brand markers because Tyler is a marker snob.

(Tyler here: The store-brand ones bleed too much!!)

Each person posts their sketches on the board and talks about what they saw and how they were trying to solve the problems. The conversation around the sketches is just as important as the sketching itself.

Photo of me presenting some of my terrible sketches

The goal of the sketching session is to give the designers some ideas on how they might solve the problems that the patterns represent. We do multiple sketching sessions until people feel they have enough material to explore.

Focus on small screens first

For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.

If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.

If you nail the small screen design, the larger sizes will be easy by comparison.

Sprint daily activity — Quick design iterations

We move immediately from sketches to testing our ideas in the browser. We create quick prototypes of the designs that we then share with the client team in Slack.

The video above shows collaboration happening on day 2 of a new project. We’re showing simple small screen designs in the browser and getting feedback both from our co-workers and the client team.

Often, we will have members of the client team working on patterns as well. They may be sharing mockups, photographing sketches, or even coding prototypes.

What matters most is that we’re sharing ideas quickly and iterating towards better solutions.

LICECap, the worst named, best tool ever

One of the advantages of designing in the browser is that we’re able to demonstrate how things should interact. But when we’re working with distributed teams, we need a tool to show the interaction.

That’s where LICECap comes in. LICECap makes it easy to capture screen video and save it as an animated gif.

So instead of saying to a client, “imagine we hide all of the controls behind a single button until someone clicks on it” and hoping that the client understands, we simply post an animated gif in Slack.

Animated gif showing add to cart interaction

The animated gif eliminates confusion and facilitates quick feedback.

Mid-sprint review meetings

The amount and frequency of review meetings in a sprint change from project to project, but generally we’ll have one review meeting late in the first week of the sprint to make sure we’re on the right track.

We share our screens and show any in-progress work. Those who have been active in our shared Slack channel will have seen most of the work already, but the meeting ensures that all stakeholders are looking at the patterns early in the sprint.

Depending on the complexity of the pattern, by the second review meeting we’ll have examples of how the pattern will adapt as the screen size increases.

Sample two-week sprint schedule

End of sprint review

At the end of the two week period, we have one final meeting to review the progress on the patterns tackled during the sprint. Nothing in this meeting should be a surprise because we’ve been sharing our work throughout the sprint.

After we’ve reviewed the patterns, we talk about what worked well during that sprint and what we could improve on for the next sprint. We’re not only iterating on the designs, but on the process itself.

This isn’t rocket science, but it feels new just the same

Nothing I’ve described here is new.

Agile processes have been around for years. Many people have talked about how responsive design makes pattern libraries more important than ever.

But the combination of responsive design, patterns libraries, sprints, gifs, and constant communication via Slack creates a radically different design process. Even if the pieces that comprise them aren’t new, Responsive Design Sprints certainly are.

Most importantly, Responsive Design Sprints work exceptionally well.

They helped us convert complex interfaces that seemed insurmountable. When we were asked to convert an e-commerce design to responsive in only three months, it was Responsive Design Sprints that helped us move quickly and finish the project a week ahead of schedule.

I can only imagine how stunned 2008 me would be to see what our design process looks like now.

Converting an existing site or app to a responsive design

Over the last few years, we’ve converted quite a few existing sites and applications to responsive web design. We’ve gotten pretty good at it so I thought I’d share our process.

Not a full redesign

Many of our clients have come to us with desktop sites that are working well that they are rightly afraid of messing up.

For example, when we first starting working on the Walmart Grocery site, the main Walmart desktop site had recently undergone a major redesign effort. We liked the new design, and were pleased to see that the designers had already considered touch-friendly targets.

Walmart.com Homepage

Given how recently Walmart had redesigned the site, any responsive plans that required a full redesign were non-starters. This wasn’t the time to rebrand the site.

In addition, Walmart and many of our other clients are running successful businesses on their desktop sites. They conduct user testing and constantly analyze site usage to optimize performance and profits.

Therefore, our goal has been to convert the site to a responsive web design with as little disruption to the business as possible.

Not a responsive retrofit

At the same time, these projects have been much more extensive than a responsive retrofit. Ben Callahan has written about several techniques for responsive retrofits. In the article, Ben poses the following scenario:

To start over with something like this would be a year long project costing hundreds of thousands of dollars. Is there anything you can do with just CSS to make the existing experience a bit better for smaller screens?

Ben does a wonderful job describing the techniques people can use to apply CSS with scalpel-like precision to start a site on their way to responsive without making major changes to the underlying code. If that’s the constraint you’re working with, I highly recommend his article.

For the most part, our clients have different constraints. They don’t mind changing markup if necessary. And they expect the CSS to change quite a bit.

What they want to preserve is the wide screen experience because that is what is currently working and what their users are accustomed to.

Responsive conversions

If they’re not responsive redesigns and they’re not responsive retrofits, what do we call projects where an organization wants to move to responsive design, but wants to preserve the desktop experience?

For lack of a better term, I’ve been referring to them as responsive conversions.

The desktop experience will have to change some

Clients often seek to preserve the desktop experience for completely understandable reasons. This often leads to a mandate that the “desktop site cannot change.”

Unfortunately, it isn’t possible to convert a site to responsive design without some changes to the wide screen version. Inevitability, there are situations where tweaks to the desktop experience would make the responsive implementation significantly easier.

And more times than not, the changes that come from figuring out how to design the mobile experience make the desktop experience better.

For these responsive conversion projects, our guiding principles have been:

  • We will do our best to keep the wide screen experience feeling as close to its current experience as possible.
  • Under the hood, we’re free to do whatever is necessary to make the site responsive.

We strive to make the experience better no matter what size screen someone is using.

Breaking the existing site into smaller patterns

Our first step in converting an existing site into a responsive design is to identify the patterns we think we will need to design.

This process usually consists of a couple of team members sequestering themselves in a room and reviewing the site and writing on sticky notes what patterns they see. This pattern identification provides us with a guide for estimating the time we think projects will take.

The results of a high-level pattern identification.

Recently, Charlotte Jackson wrote about an exercise that teams can undertake to identify patterns. We’re looking forward to trying this on a future project.

Ordering the patterns into sprints

After we’ve identified the patterns, we start organizing them into sprints. Some of the things we consider when organizing the sprints are:

  • In general, we want to start with the smallest patterns and build up to the most complex.
  • We check with our client to see if any components are particularly important and need to be addressed earlier. If so, we figure out any dependencies for those components and prioritize them.
  • As each sprint passes, our velocity increases as does our ability to tackle more complex components.

patterns-into-sprints

The whole point of agile is to be flexible so this plan isn’t set in stone. But it does give us a starting point and lets our clients know what they need to prepare for each sprint. Our client team plays a huge role in making each sprint successful.

Responsive Design Sprints

The biggest change to the way we work is that we now design in sprints. Responsive design sprints are a topic worthy of their own article and I plan to write more about them soon.

In the meantime, here are the highlights of the way we approach these design sprints:

  • Sprints focus on patterns.
  • We work with the client ahead of time to determine what patterns will be tackled in an upcoming sprint.
  • At the beginning of each sprint, the client team presents everything they know about the patterns—how and when they are used; what user testing has been done; and any edge cases we need to consider.
  • We then start sketching small screen versions of the patterns.
  • Once we’ve got a good direction, the team divides up the work and starts designing in the browser.
  • We share what we’re designing with our clients nearly every day via Slack so we’re constantly adjusting and refining the designs.
  • At the end of our two-week sprint, we’ve got working prototypes of those responsive patterns.

Sample two-week sprint schedule

There is much more to say about this process. Read my follow up article on The Power of Responsive Design Sprints.

Rinse and repeat until we’re “done”

Once we start the responsive design sprints, we simply continue the formula until all of the patterns and components that we’ve been tasked to design are complete.

One of the interesting things about this process is that the definition of what “done” means changes from project to project. There are a couple of reasons for this.

First, our client’s engineering team is often responsible for taking our work and integrating it into whatever backend system they use. In these cases, our work can be complete long before the site launched and officially “done.”

Second, we’re frequently asked to teach web teams. On more than one project, we’ve had designers and developers from the client’s team embed inside our team to learn from us.

This means that we start projects with the goal of teaching the team to fish for themselves and once they can, we hand over the project to their designers to finish things up.

The process works

When we’re confronted with a complex fixed-width interface, I often have no idea what the responsive version of that interface will be. But I do know even the most complex interfaces can be converted to a responsive design by breaking them into smaller patterns and designing in sprints.

I have complete faith in the process because I’ve seen it work multiple times. If you’re stuck on a complex responsive design, I recommend giving it a try. If you need help, let us know.

(P.S. You may enjoy my follow up article on the Power of Responsive Design Sprints)