Interface on a string
How a thread reel helps design and assemble complex interfaces
It happens that the interface architecture comes up with one person. He knows everything in it to the last detail, to the most insignificant scenario. He is familiar with every element, every action - because he is their author. And this person is the only one who keeps in his head the entire web of intricacies of the interface, say, a new service.
But here we will talk not about architecture as such, but about the problem of transferring knowledge about the new interface to the project team (development team). Usually this step takes a lot of time and is the root of most development problems. To assemble the designed interface into a ready-made service, it is necessary that all project participants (developers, web technologists, designers, and the architect himself) have a single and complete idea of the future service. The team needs to understand every detail of the interface, every scenario, every element. All team members must see the whole picture. I will show which method we have chosen and what benefits have been gained from this.
A similar problem arises when assembling complex interfaces, when most processes are conducted in parallel: additional functions and sections are designed, new scripts appear, new interface pages are assembled, tested and integrated into a future service. If each participant does not know how this or that change or addition will affect the whole architecture as a whole, how it will change the scenarios and how it will affect its current work area directly or complicate work with the new site; if each participant cannot promptly adjust the work of others and, in particular, the architect, then the interface assembly itself (and, especially, subsequent debugging) can take (and often always take) no less time than the development stage itself. Usually, in such cases, the quality of service (I mean the general summary characteristic,
Since in our case we are talking about a startup with a complex interface containing a large number of elements and overlapping scenarios, the work on its assembly was carried out in parallel with its completion. It was vitally important for us to save time at endless meetings and achieve the work of the team as a single consciousness, instantly coordinating the actions of all participants with each other and adapting innovations and changes in the interface to the realities of the ongoing work without the need to spend hours on meetings trying to convey to each other our thoughts.
None of the approaches to joint development that we tested earlier fully satisfied us: software solutions did not allow all participants to see the whole picture, marker boards did not allow us to see each element as it would be on the finished service in the assembled interface. In a word, nothing suited.
The solution for us was not only interesting, but also simple and extremely cheap. They still remember how the detectives in the films (or Russell Crowe in The Mind Games) investigate convoluted crimes by pinning any facts or photographs of the participants to the board, then tying them together in a thread in accordance with their relationship to each other in the form of a certain graph. And everyone knows what flowcharts are. Having crossed these two methods, we got a really convenient tool that completely satisfied us.
We needed: a thick thread, scissors, power stationery buttons, stickers to indicate places of signature, paper, a color printer and one plasterboard wall, which was not a pity to spoil.
All we did was hang printed pages of the interface on the wall and tie them with a thread, tying it to the power buttons. Threads of the interface were connected in accordance with user scenarios, and we indicated the direction of movement of the user by gluing a sticker next to the thread.
The whole team moved to one room and now everyone could see the interface as it was seen by the architect. Now everyone could see everything. Work has become well-coordinated and fast.
Designed pages were gradually replaced by screenshots of real collected ones. Developers processed many plots at once in parallel, because they saw the whole picture and could optimize their work. The architecture also grew and the service was supplemented with new scenarios and functions, but, because all processes were in continuous coordination and before our eyes, this no longer slowed down the team’s work and was going on painlessly for the project.
As a result, we saved about 40% of the time in debugging user scripts after completion of the assembly and integration of the interface, and in the development process itself.
PS. Who cares what service we collected in this way, it is here .
UPD. If you still decide to sacrifice the office wall to your project, I advise you to use colored threads in addition to stickers.