The design of an information environment should start with its conceptual model. Doing so gives the team a high-level understanding of the tasks people will do there, the elements and actions required for them to complete those tasks, the sequence they need to happen in, and — ultimately — the purpose of the environment. You can’t gain this understanding from sketching user interfaces; you must begin at a higher level.

I’ve often seen designers jump to UI design too early in the process before they have a clear grasp of the system’s conceptual model. This is understandable: models are abstractions, and abstractions are difficult to talk about. People love seeing and discussing UI; it feels like “real” progress in the project. (This is true both for designers and stakeholders.) However, starting with UI causes the team to miss the big picture, and often leads to incoherence down the line — especially as systems get more complex.

So how do you get designers and stakeholders to discuss the conceptual model without reverting to sketching UI? One approach that works for me is to ask the team to stop thinking about the thing we’re designing as software and start thinking about it as a place. How did people fulfill these tasks before digital? What kind of place should this be? What spaces does it need for people to accomplish their goals? What would people expect to find there? What do they expect to do with those things? Etc. For example, if you were designing a workforce training web application, you could start by imagining it as a physical environment (say, a school) rather than as a website. Needs and spaces could vary by user type (prospective students could have different needs than current students), by the ​degree of sociability​ required (individual study rooms versus classrooms), or by a variety of other factors.

The point is not to design a physical school; team members know the ultimate goal is to design an information environment and that they don’t need to take the analogy literally. The point is to get them to break out of thinking in terms of UI elements so they can:

  1. identify the tasks, objects, groupings, relationships, actions, etc. that will comprise the system,

  2. define the names and attributes of those things, and

  3. think through the choreography required for people to fulfill tasks in the environment.

With a solid understanding of the conceptual model, the team will be able to have discussions about the UI and how serves (or doesn’t serve) user goals. They will be able to test, iterate, and refine the UI and the conceptual model itself. But this is only feasible if they start from the conceptual model and then move to UI — it doesn’t work the other way around.