Get your interaction model right :)
“Whenever I start working on a new project, the first question I ask is ‘what is the interaction model’”.
This is what Gaurav Bhushan, now head of design at Viv labs told me when we started working together.
An interaction model is not easy to grasp and make sense out of. It’s often thought about “later, let’s now start building…”. But it very often proves to be costly over time. The same way great film directors do not start filming and worry about the script later, no designer or engineer should start building products without defining their interaction model.
But I get that it’s hard, and here’s why I think it is.
In the diagram below, structures and models are represented in a hierarchical order. Every structure type has a model type that defines its behavior.
At the very top of the pyramid, sits the interaction model. It is intended to define the behavior of the system. This makes it tricky.
If you take the time to define all the things that are in that pyramid, you’re be going towards a waterfall approach. If you don’t, there are too many uncertainties and your interaction model might need to be adjusted regularly… So how do we stay agile AND build a robust interaction model?
By using the two lower layers, services and features, you’re looking at the fabric that forms your system. Sure, your features and services will evolve and might completely change over time, but it won’t happen over night. Ultimately, defining how your different services interact with each other is your interaction model. I see it as the tool that helps you define the scope and the navigation of your system.
The tricky part is visualizing it all in one, simple, “mother of all” diagrams that sums it all up. By glancing at it, you know where you could face complications in building your next feature or setting up a migration and what constraints you need to consider.
There are no standards or clear best practices out there for visualizing it. Every system is built differently. Some people use an isometric view to represent the core services of an app, others use diagrams (varies from simple to very fancy). So get creative and build yours the way you find it to be most sensible.
Remember, it’s meant to be simple. It’s supposed to be used as the one document that you show anybody to explain your system and they go “Oh! Now I get it”. Until you get that reaction in under 20 seconds, your model is not there yet.
Maybe one day I’ll have enough experience to see a clear pattern and propose a standard way of putting together the perfect interaction model visualization. Until then, stay creative and keep building.