Conceptual Models: Core to Good Design
This is an excellent, short, powerful reminder of an often skipped stage of the design process. It should be required reading to all designers. I just wish it had more examples.
- Most people think Interaction Design is UI design. It’s deeper than that. It includes all concepts that an application exposes to users.
- Interaction Design consists of concepts, task flow, and presentation.
- Whether or not designers create a conceptual model, the application will have one.
- Focuses the design process
- Supports development
- Makes an application easier to use
- Makes documentation easier to create
- It describes
- The task-domain, purpose, and high-level functionality
- The concepts exposed to the users
- The relationships between these concepts
- The task-scenarios supported by the model
- Information architecture is similar, but different than a conceptual model:
- It is concerned with organization and structure but doesn’t always present the operations and task flows.
- The user’s mental model is different, or an interpretation, of the conceptual model. There will always be differences between them, and each user will bring his own context and background into his or her interpretation.
Structure of a conceptual model
- Purpose and high-level functionality
- Major concepts and vocabulary
- Objects/Attributes/Operations/Relationships analysis
- If something isn’t in the conceptual model, it shouldn’t be exposed to users.
- Anything a user can do, they can do to an object. No operations can be objectless.
- The conceptual model shouldn’t dictate the interface. Objects and operations should be possible using any kind of interface.
How can designers make a model easier to understand?
Metaphors - can be useful but also harmful, as users might bring assumptions about the reference that the application does not fulfill.
Progressive disclosure - Copying machines used to have a “flap” to hide advanced controls.
- Start with user research
- One designer should drive it; with input from everyone else
- Include engineers, but beware that they might want to expose unnecessary concepts from the implementation side.
- It is never right the first time, so iterate.
- It should be an ever-updating source of truth for decision-making.
- Could be a simple doc outline, a spreadsheet, or an object-relationship diagram.