The meeting, set weeks in advance, should have been easy. The first “here’s how we think it should look and feel” web design concepts presentation is normally driven by insights from the discovery process and the start of the wireframes. But there was a problem: The client could not agree internally on the strategy and focus of their new site.

It could have been awkward. It could have been an unrehearsed pas-de-deux between two dancers who are unfamiliar with each other and the work. Or it could have been a planned confrontation between opponents, each wanting to stride away from the ring as the victor but not do any real damage.

What rose to the surface instead was the remarkable coexistence between the client’s own ambitions for creating genuine impact in their industry, and the business requirements that drive and define their quotidian operations. For most of the meeting the conversation orbited around this question: How much should the requirements drive the design, or should the design largely shape the requirements.

One of the higher-ups on the client side eventually asked, in effect, “Should we use this design to help us prioritize and focus our business requirements to help manage sprawl in our business requirements?”

Chicken? Egg? Yes!
Let’s not get all dewey-eyed here over the power of design. Converting client business requirements into a solution that not only meets the needs but “plusses” them in some way is the name of the game, and ’twas ever thus. But in the world of digital marketing, where the lines of distinction between the experience and the function are beyond blurred, we can see the numerous opportunities made available when we allow the form to help streamline the function.

Consider, for instance, an airline’s app. It needs to function differently from the airline’s web site, if for no other reason, because the app is most likely used on the go, with one hand, and probably on a dodgy 3G connection. So the business requirements for strong cross-selling might be pared back to ensure unfettered data delivery and an easier-to-thumb-tap user interface.

These challenges are particularly acute when we consider the ramifications of responsive web design and presenting data and content across multiple platforms; having a single monolithic design footprint is not sustainable, and business requirements become a pyramid of functional opportunities based on device capabilities, bandwidth and screen size.

Some other observations from the meeting include:

  • The process of working through the wireframes and getting into design is rather more like flying a helicopter than driving a locomotive: it’s a finesse game that greatly benefits from the kind of team-wide trust that ensures full disclosure.
  • This finesse game happens as the function starts to be realized in a form. The first iterations of a design solve many issues, but they also point out gaps in the team’s discovery work as well as the client’s business requirements.
  • These gaps manifest themselves as the space between “I love that layout but it doesn’t do what we need” and “Our requirements are going to clutter that design, and maybe that’s our clue to apply a new filter to the business.”

Team Members In Tights
My recent meeting experience was a truly remarkable collaboration between a client team that sees an opportunity to leapfrog their competition, and an extended team of design, marketing and technology specialists who each are tops of their fields. The dynamic tension was never between teams, but instead was always focused on getting shared project goals as right as we can, right now.

It was the kind of meeting that reinforces how important the team’s mutual respect and coordination are to achieving what is a shared accomplishment. Just like both Svetlana Zakharova and Kane, everyone in the meeting is applying their expertise while in the equivalent of close-fitting bodywear, making the conversion of business requirements into an interactive experience a highly revealing exercise.