When I attended IxDA in Savannah USA last year, one of the most interesting and relevant talks that I went to was that of Dan Brown of Eight Shapes who discussed Concept Models.
(You can also download a video of this talk from the IxDA website)
What are concept models?
Concept models provide a visual representation for user interactions with a system. Objects and actions are related to each other in a diagrammatic form “e.g. Man walks dog” – man and dog being objects and walks being the action.
For an example of what I’m talking about check out Dan’s example: In Which a Concept Model Makes Me Giddy
Why use concept models?
As an Interaction Designer you’re often considered the ‘glue’ of an IT project, translating lists of business requirements into schematics that designers and developers can understand.
Dan Brown cites in his article:
From In Which a Concept Model Makes Me Giddy
- It highlights aspects of the design problem that are otherwise buried.
- It shifts the conversation from technology to impact on the organization.
- It draws connections between concepts that seem otherwise distant.
- It uses labels for the connections like “reveal”, “conceal”, “limit”, “enable”: real active verbs that convey something more than belonging.
- It allows me to eliminate ideas that are not essential to the overall story.
- It encourages me to place loosely connected ideas into context.
In my experience concept models are most valuable in these three stages of an IT project:
1. When the project is being handed over from Business Analysis to IA/Design: They’re most helpful on large scale projects translating requirements from a document that Business Analysts had collected to something conceptual that designers can understand.
2. As the design/idea generation process continues: Designers love coming up with requirements of their own; this isn’t necessarily a bad thing as mostly they help to push the work further than the client’s original expectation to meet the true user goals / goals of the project. In this instance concept models are great for understanding where these additional requirements ‘fit’, and also to rationalise any conflicting requirements.
3. When scope changes: Particularly in large scale projects as schematics or designs are starting to form, when clients see what they’re really getting, clients often have additional features they’d like to add, alter, or even sometimes remove from the system. By having a conceptual framework to visualize the system helpful when all parties are explaining the changes to be made.
Care to comment?
Have you used concept models or something similar? Do you have any questions about concept models? As a developer would you find these helpful? Please comment below.