Conceptual models

It is hard to win when you are playing by someone else’s rules or, worse still, do not entirely understand the rules. By redefining the “meaning” of your project you become an expert in the rules of the game, and one of the people defining those very rules.

The Meaning to Tasks model uses the idea of a “project meaning”.

It supports a practice for teams and individuals to create fundamentally new meanings for projects, products and services. By working in this way the meaning of everyday projects are changed, and projects created are differentiated from the rest of the market through innovatively integrated strategies, rather than solely through feature-level improvements.

Making a sketch is often the first step towards thinking about a design problem. But I’ve found that oftentimes making that mark feels daunting – it is the first sign of my imagination committing to a solution. A mark feels risky – the idea is now out in the world for more than just me to see.

I often think of sketching an idea as making a visual list. Making lists helps move ideas forward, another kind of decisive first mark. I also think about list-making as a process :

1. Make the list (Thinking out loud, possibly in collaboration)
2. Looking through the list again and re-ordering it. (Fitting it to the needs of the idea)
3. Reviewing your new list (Critique and time for contemplation)
4. Fixing the list and deciding to follow its order (Deciding on a course of action)

With sketching, or visual thinking, these steps happen simultaneously, still holding a lot in common with a simple list.

Here’s an example from one of our recent projects with MIT’s Wolk Gallery for a exhibition promotion piece.

One of several sketches which emerged from this visual thinking process.

The Final Design

Although this process seems based in a visual product, I apply this kind of visual thinking (or visual list-making) many kinds of problems. Because of the quick nature of the process, we’re able to address many questions and answers early on, helping to shape a project’s outcome in the process.

This conceptual model addresses the interrelationship between several layers of a design process – from broad vision to specific goals to strategic approaches to actionable tactics, and finally to essentialized tasks.

Using this kind of conceptual model for a project allows for a number of desirable outcomes:

1. It acts as validation process for new ideas that may be created through the design process.
2. It is inclusive of user and business goals and allows the two concepts to exist in a common holistic project structure.
3. It allows for the questioning, iteration and/or reshaping of the vision and goals for a project.

The important question to ask as this structure is created is how does each successive step support the ones above it? This question can lead to two conclusions:
– the goal, strategy, tactic or task does not support the next node in the tree
or
– the next node in the tree needs to be modified to make it work with the new creative thought that has been created

Like all processes I advocate for, there is no “right way” to start this process:

– If you have many specific ideas, list them out and start grouping them into concepts to see what strategies emerge. Then, work your way up the nodes of the tree.
or
– If you have burning vision for a project or product, start at the top of the tree and lay out all the nodes in the tree that will support this vision.
[Diagram : Example concept map.]

(Click the image to see a larger version)

Here is a simplified example of this concept model as mapped out for a company that aggregates content, such as a search engine or blogs etc.

This strategic tool is useful for validating new ideas in a process. Running a new idea through the exercise of asking “what strategy or goals does the idea support?” clearly shows its pros and cons.

Crucially, a team that has created this tree structure, and agreed that the points on the tree make sense, has a baseline starting point when new nodes are introduced the team. This is important because no matter where the idea comes from – CEO or intern – the idea must support the team’s agreed upon structure. If the new idea does not support this structure, either the current structure is wrong (possible though less likely after fully following this process) or the idea has flaws that are exposed by running it through this process.