I’ve been fascinated by levels of description for as long as I can remember:
- physics, chemistry, and biology as a kid – with both expected and emergent properties at each level
- neurology to consciousness as an undergrad
- different levels of selection in (and beyond) evolutionary theory in grad school
- abstraction and realism in comics during my brief tenure as a web designer
- low- to high-fidelity with user interface design (wireframes, mockups, etc.)
- methods, classes, libraries, applications, and ecosystems, and how similar design patterns can be applied at each over the past couple of years
- requirements, implementation plans, and code in my daily work
I think the impact of choosing the right level to discuss a particular problem can’t be overstated – to paraphrase Einstein: discuss things as generally as possible, but no more generally. Check out any work on wireframing or paper prototyping and you’ll hear exactly why this is important: discussion tends to happen at the finest-level of grain you provide.
If you give someone a wireframe with actual user interface elements, they’ll argue over whether checkboxes or radio buttons are appropriate – not whether there’s more or less information on the page than there should be. If you give someone a mockup in color, they’ll debate over the shade of blue you used – not over whether the elements of the page are in the correct relationship to each other. If you present a new project by showing code, they’ll argue over database schemas and method names instead of whether you’ve actually solved the problem at hand.
So: be aware and intentional about how you communicate, and make sure you’re talking about things at the right level.