Modelling Best Practices: Conciseness

Conciseness of a model is just as important as clarity and consistency.
A model is a simplified representation of something.

By definition, it should only contain what is essential to the idea it is representing.

Think of a map – to show a large area, you let go of details, while focusing on what the map was meant to show.

A model is concise if removing an element creates a gap in meaning.

A model is cluttered if it has superfluous details that could be moved elsewhere without impacting the overall idea. This includes obvious information that the user of the model should be able to assume without any help.


Let’s use a process flow as an example again – they tend to get cluttered, even if with the best intentions.

The first model looks very busy, to the point that it is hard to follow where each connector goes. Is each box in this version adding useful information?

Let’s look at how we can make the first version more concise:

☑️ Include only what is important to solve the problem

☑️ Omit the obvious

☑️ Don’t replicate information

☑️ Minimize linear activity sequences

☑️ Priority to flow and relationships

☑️ Use the least number of words

☑️ Don’t replicate conditions as activities

☑️ Don’t mix up high-level with detailed


To keep your model as concise as possible, include only what is relevant to the business problem:

  • Use the shortest words possible.
  • Use the least number of words. Drop articles, prepositions and adjectives unless removing them changes the meaning. Drop obvious words.
  • In process flows, minimize linear sequences that can be combined into one activity. If an activity has a lot of steps that are always executed in certain order, they may be described in documentation, or its own mini-flow.
  • Don’t replicate information. If connectors indicate who sends and who receives information, it’s not necessary to include it as activity or comments.
  • The flow or relationships in a diagram should not be overcrowded by boxes. If the flow becomes lost in detail, zoom out and consider a high-level model supported by more detailed fragments.
  • Do not load the model with comments, unless they are vital. Comments and narrative belong below the model.
  • If you feel you need to add more elements to the model, consider whether you are trying to squeeze two ideas into one model. If so, split it in two.
  • Don’t include elements that do not participate or impact other elements.
  • Don’t include non-essential information about elements, such as adjectives or other descriptors.
  • Consider using colour or format instead of adjectives. E.g. highlight problem area with colour instead of labelling it.

You will not win respect of your stakeholders by making grandiose, convoluted or intimidating models.

Remove anything that can be removed without taking away from the main message.

Create the model with the audience in mind – your goal is the shared understanding of requirements.


Based on the book “Business analyst: a profession and a mindset”.

Please share your thoughts!

error: Content is protected !!
%d bloggers like this: