arrow-forward arrow-back hamburger facebook linkedin medium twitter modal-dismiss caret menu cross telephone map-marker
Skip to main content

Blog

Modeling (no, not that kind)

default blog post image

More and more, clients are coming to us looking for help training their more junior staff on interface and interaction design issues. To do this, we typically conduct group work sessions, reviewing key principals, processes, and deliverables we’ve found to be best practices. We usually follow these sessions up with individual, more context specific, coaching or design reviews to offer advice on implementing these best practices in their projects.

After just a few of these engagements, I realized that perhaps the most valuable topic is also one of the hardest to learn how to use effectively – information modeling.

Information modeling, or just modeling, in the context of product design, is the process of documenting all the known things, people, places, and actions, then assembling them in a way that makes clear the structure of all connections, relationships, and hierarchies of a particular concept (or service, product, features, etc.). It is a general process through which we can rigorously investigate and document complex concepts. We do this with the belief that through a deep (and shared) understanding of the way things ARE we can develop simple and harmonious design solutions for the way things SHOUD BE.

I had the privilege of learning nearly everything I know about modeling from Hugh Dubberly, undoubtably THE expert on the subject (among many other things). I remember, very clearly, not understanding the point of the first modeling assignment Hugh ever gave me. It took me many years of trail and error and coaching to really understand why, how and when to model efficiently and with purpose. Learning the mechanics of creating a model is straightforward. Understanding what, when, and how to model in the context of your particular design problem can be harder to grasp.

That said, there are a number of models that we create on a regular basis for our projects that we’ve found to be appropriate for a number of specific reasons and contexts.

These include:

  • Product Models
  • Service Models
  • Technology Models
  • Data Models
  • Process Models
  • Navigation Models

Over the next few weeks I’ll be documenting a few of these and describing how they connect to our larger design process and adjacent deliverables.

Partner

Gregory Baker

Contact icon

Let's talk about your needs and how we can help. Get in touch

Contact icon

Interested in joining the DesignMap team? Let us know