Contact Us
Crux Collaborative

The Secret Ingredient in Responsive Workflow

Related Services: User Experience Design, User Experience Planning and Foundation

Many brilliant minds in interactive have written and presented on the subject of responsive design workflow. There are numerous articles, books, and blog posts that address how a traditional “waterfall” process no longer works, that we should build mobile-first, and tools you can use to improve responsive workflow.

Much of what’s out there suggests there is a magic formula – a certain tool or a particular philosophy – that will result in a successful project. At Crux Collaborative, we have come to a different conclusion.

We believe that there is no perfect tool or philosophy when embarking on a responsive project. (Sorry.) Responsive design itself is merely a technique – it doesn’t automagically solve problems for users. There is only one thing that can ensure your project will be a triumph: a truly collaborative process.

How do you begin? 

What are the deliverables? Which discipline kicks it off?

Getting started can seem pretty daunting at first. How do you begin to design an experience that must be so flexible?

Prior to responsive design, we’d plan for “x number of wireframes” and design “x number of page comps” to establish the core system. Clearly, this doesn’t work anymore. And no longer can a UX specialist – or any other team member – create concepts in a vacuum.

Instead, we tailor the approach for every project with a single goal at the outset of the project: get into the browser as early as possible. Inspired by Ben Callahan, we believe that ultimately the only “deliverable” that really matters is the final prototype/site.

That does not mean we’ve abandoned all our old ways of getting work done. We still use various tools from our toolbox like Photoshop, UX Pin, and Axure along the way – but we limit the deliverables we produce using them. The tools that were often the foundation and primary source of  deliverables now merely help us work toward the point that we have something to build and refine in the browser.

Involving Everyone

Getting Clients on Board

Clients understandably may be skeptical about receiving only one “deliverable.” After all, documents and decks are what they’re used to buying and distributing to their internal stakeholders. It may seem confusing and risky to them at first, they may misunderstand and think you are proposing to “skip” those steps.

Three aspects about our culture have helped us convince our clients of this approach.

  1. Mutual Trust. As a team of consultants, we have always made specific recommendations rather than providing our clients with several choices. Our (unofficial) motto is: “amateurs provide options, experts provide recommendations”. Our clients trust our expertise.
  2. A history of collaboration. Prior to our responsive work, we already collaborated closely with our clients and worked together to define solutions, rather than creating solutions on our own.
  3. Transparency. We don’t “hide” the work in progress from our clients, they see it, and participate in creating it, at each step of the way. So in the case of responsive and one “deliverable”- waiting a bit longer for a “deliverable” doesn’t equate to waiting to hear or see what’s happening.

We cannot emphasize this enough: collaboration is the secret ingredient.

Clients who are actively engaged in creating solutions will understand and believe in the process so much more –and persuade other stakeholders of the value. Clients who collaborate have more ownership, pride, and expertise in the solutions you create together.

One size does not fit all. The process you use depends on the team you have.

We see each project as an opportunity to evolve. Over the years, we have amassed a veritable library of methods to apply to projects. There are basic best practices up front, but we believe it is important to adapt as you go based on discoveries along the way. The milestones, methods and tools should themselves be born of a collaborative process – and should match the team personalities, strengths and skillsets.

For example: For some project teams, a daily stand up works and for other teams it can be a colossal waste of precious morning time.

Another example: Identify how team members and clients like to receive and process information. If your team is comfortable with ambiguity and problem solving in a group, go for it. If this type of environment causes some team members to get tense and shut down, have time for individual problem solving prior to meeting as a group. A group sketching session is not always the best approach.

We think of this flexibility as a kind of “remix culture” – mixing the best methods we know to fit the people using them.

Our Projects: Step By Step

Image of sketching templates and markers for getting to a concept. Next to image of a hand holding a phone, testing a prototype.

 

Getting Started

All projects need to start with defining business and user objectives. Before you make something, you need to know the who, what, and why.

Once you have your objectives established: Content First

Because we specialize in data-driven, complex user experiences, content often takes the form of data. And because we work with regulated industries that require several levels of approval, detailed, approved content is rarely available at kickoff. Typically, enough is available to generally structure and prioritize what will need to be communicated (no wireframes, just lists).

Getting to a Concept

Next, our team grabs stencils and markers – it’s time to surface expertise from all disciplines and subject matter experts (SMEs) through collaborative sketching. We all work together to get better clarity around constraints, to begin to identify issues, and to arrive at a conceptual approach everyone can get behind.

Get to Prototyping

What does “prototyping” look like given the people on your team and the time and resources you have? It varies and doesn’t really make that much difference. The thing that matters is that you can interact with it in a browser at different viewports. One thing is certain — showing always beats telling.

Initial prototyping can look fairly traditional, done by a UX-er in Axure, UX Pin or any other number of tools. It can be done in code if you have a front-end designer/developer who is comfortable with this type of group collaboration. It can be pattern libraries to set the atmosphere of the project. And, yes, it can still be Photoshop files if you have a code-minded designer!

The success of any of this approaches is contingent on the team having a solid understanding of the business and user objectives; a familiarity with the constraints; and being comfortable collaborating.

We haven’t found a lot of a success with the “send one resource or department away to figure it all out and show it to the rest of the team” method when it comes to responsive. The amount of work that is completed should be limited before regrouping. Invariably, things change as the prototype comes to life, feedback is given, new discoveries are made, and new content becomes available.

For example: You may take a look at the content at a certain breakpoint and realize you need to reassign content priorities. You may realize the tidy content works great on a smartphone, but makes the page feel empty on a large desktop monitor. You may realize that the tabs do not actually fit within a typical smartphone width.

The Importance of User Testing

A Finished Prototype? Not so Fast…

You may be feeling pretty good about your progress, but you don’t have a true measure of your success if you end user doesn’t feel the same way.

One thing we can state with absolute certainty: You won’t discover or resolve critical issues with your design if you don’t include actual users.

Getting the content and functionality to work so that it makes sense to the project team doesn’t mean that it will make sense to the user. And the insights you gain by conducting a usability study of the prototype you would never have been able to figure out on your own.

For example: You may discover that the majority of users are looking for a specific piece of content earlier in a mobile viewport than the content prioritization planned for, that the hitspace for a key user action is too small, or they are consistently scrolling past a piece of content that includes contextual links and inadvertently triggering them.

You Found A Problem: Now What? Don’t Worry, it’s a Prototype

Remember when we talked about reducing the emphasis on  the usual “deliverables” like wireframes and comps to get to the browser more quickly? You saved time at that stage because you wanted to get to this stage.

It’s a prototype so you don’t have to worry about taking it all apart and putting it back together, updating previous deliverables, re-annotating wireframes, etc. There is no exponential amount of previous work to unwind and redo.

Your team and the clients have been working together to create a highly flexible solution that meets both business objectives AND user objectives. Now that you’ve been able to identify usability issues, you can resolve them quickly and move forward with a  solid, well-built deliverable that everyone can stand behind.

Wait, There’s More 

Notes on Collaborating in Responsive

  • Early in the process, you figured out how your team absorbs information. This needs to be a constant flow throughout the project. You can’t expect the person who helped prioritize the content to disengage for weeks and then come back into the fold and not wonder why their idea is no longer exactly as they left it.
  • There’s no way around it, it takes a time and people investment. And the people investment doesn’t come in clear and separate phases – you need a dedicated team for the duration of the project.
  • Be careful about getting attached to an idea. It may work well in one size and completely fall apart in another. Be flexible and open. The scrap heap of unused ideas is much larger in responsive projects!
  • Don’t forget to include the SMEs/client in your problem solving. If you realize a piece of content is unwieldy in mobile but don’t include clients in resolving the issue, you may waste project time and budget developing and proposing an idea that can’t or won’t be implemented due to anything from political to regulatory reasons. Great clients don’t expect you to know it all, they expect you to be interested and engaged with developing the best solution.

There’s no way around it, responsive projects are tricky. The old methods, tools, and processes don’t work. And the landscape changes daily. But using a collaborative approach is the secret ingredient that will help your team manage the complexities and come through victorious.

If you’d like to learn more about collaborating on a responsive project, get in touch. We’d love to hear from you.

All Insights in these categories: User Experience Design, User Experience Planning and Foundation

Related Insights