Technical requirements in diagrams and illustrations – why not? Let’s see how such an idea can make the client happy.

Visualization: 100 pages in 10 pictures

Typically, project documentation is divided into several elements: the entity model, the distribution of roles, the roadmap, the site structure, and the prototype system. The set may vary depending on the scale of the project, the tasks set, and the agreed format of work. For example, the description of roles can be optional for developing an online store and key for creating a rating portal.

‘IT casting’: which role to choose

It is necessary to determine who and how will interact with the site to understand its general structure. Roles will give you the ability to classify users and build project logic so that each category is convenient to use it.

We propose to visualize the scheme of roles as a pyramid: at the bottom, place the usual guests of the site, and then place users on the steps, depending on their level of access and “powers”.

What is a ‘roadmap’ and how to deal with it?

To create a roadmap, you need to answer the question: how do roles interact with entities? Ask the client: “What will the user do on your site?” Is the guest going to buy something, does he need to fill out a registration form, what sections does he need? As a result, you should get a classic flowchart, where it is more important not even what you write in the rectangle itself as the final result, but the description of the path itself. The roadmap is the tipping point when your expertise weighs as much as the client’s opinion. Do not be afraid to use your experience and advise the customer on the best solutions from a technical point of view.

Prototypes

When you have defined the roles and their actions, based on them, you have prepared a detailed structure of the site, it is only a small matter – to draw prototypes. This is the final stage of development of project documentation, for the creation of which you agree on all previous actions with the client.

When you are doing project documentation, layouts should be just clear images, close to what the real product will look like. Interactive wireframes can be made later, and at the stage of agreement with the client, it will be enough to indicate with arrows or lines how the individual prototypes are related to each other.

Project documentation on one sheet will be viewed by everyone

Visualization is good in general as a communication format: the client sees what project will turn out in the end, does not waste time understanding technical terms, and even starts smiling at you. And a few more subtle advantages of project documentation.

• The client, seeing the layouts of his future project, begins to love him even before the final implementation.
• The phased approval of each visual minimizes the risk of global edits when the project is already up and running.
• It is easier to annotate images than texts. The client will immediately see the missing functionality in prototypes or an extra branch in the project structure.