Pattern based design communication techniques – Doug LeMoine

It’s always nice to meet friends from Cooper on the road. Doug, a master Design Communicator, talked about how to communicate a design based on patterns you identify. His talk can be found here.

He started the talk with describing the roles of the Design Communicator (DC) and Interaction Designer (ID) in a traditional Cooper team. I work in such a team structure and we are still learning how it works after 2 years of adopting it. We all laugh when he used a Beatles reference comparing DCs to Lennon (the word-smith) and IDs to McCartney. 🙂 Similarly, DCs can also be described as philosophers, like Socrates. They pose questions to move the designer along and help them shape an ideas into a full blown concept. I like that analogy because it is really easy to take this role for granted and simply think that a DCs test the ideas or just communicate them.

The philosopher analogy hints at the most subtle, yet important and probably the most difficult part of a DC’s responsibility – they pose questions that lead a designer in a creative journey with the final stop being an elegant solution. I was first exposed to the Cooper team concept 4 years back. The most attractive part about that partnership to me is that instead of a couple of people throwing ideas down on the table and getting no where in a fury of competition; the team structure sets up roles that have distinct but complementary responsibilities working on getting to a common goal.

I used to have to “DC” myself, (that’s probably true for everyone even if they don’t know it). I turn off my ideation part of my brain and I try to define the problem (although that’s not always entirely possible). Then I turn off the problem definition motors and brainstorm concepts. I imagine that this takes twice as long compared to a team of 2 people doing both together; especially when they are each really good at the one thing they do. This partnership can be really helpful particularly in situations where we are solving problems for really complex applications.

So to sum it up, DC’s have a tough job and they really do make designing a much more fun and collaborative process. That’s why they make the big bucks. 😉

Doug then goes on to explain the documentation methodology with a case study on a project he worked. It’s a web tool used by financial advisors to explore new ways of analyzing portfolios and understanding performance. His client was Barclay’s Global Investors. His design documentation approach uses a problem-solution pattern.

I forgot the persona’s name, but here is a little bit about him:

The big idea from the talk is recognizing patterns in your design and describe them in a way that empowers the reader to think on their own when building a living application over time. An example is to document global behaviors: “things that do this generally have this behavior”. Doug also advised that documenting similar things in similar ways throughout facilitates learning. We should aim to provide a pattern language for a particular system that lives beyond the screen layouts being designed today because every system is a living thing.

The DCs at Cooper ask these questions when thinking about how to tell the story about the design:

• How does our design help the persona get his work done?
  • User scenarios:
    • Shows behaviors in context of the problem they solve.
    • Communicates the narrative of the design.
    • Facilitates the discussion of the design in human terms.

• How does the behavior work?
  • Screen layout diagram:
    • Describes important elements and behaviors.
    • Roots the screen in context of the workflow.
    • Provides access to related detail.
• What is the essence of the solution?
  • Rationale:
    • Tells why is it good?
    • Describes why certain solutions are not recommended.
    • Tells the story of the design.
• Are elements of the behavior representative of core, repeated behaviors?
  • Global behaviors:
    • Provides principles for solving common problem.
    • Describes similar problems with similar behavior.
    • Draws connections between areas of the interface.
• How do we make all of this easy to find?
  • Table of contents:
    • Uses clear, consistent nomenclature.
    • Uses descriptive page headings.