I was always a paper and pen kind of guy. The compulsive note taker one, the one that sketches up something to explain that concept, that one simple detail, the bigger picture or basically anything. Hoarded notes, notebooks, even books and postit pieces and of course digital versions of everything. They contained ideas, explanations, documentations or just really simple notes that “can come handy later”. Naturally the comes handy later part is only true if you are able to find the right one that you were looking for at the right place at the right time. During my work I found myself looking for these pre-made sketches, drawings, notes whenever I had to explain something to a colleague, to a customer or to someone from upper management. Yeah, I have to admit, I spent way more time looking for the right piece of information then it would be necessary, but digitizing, organizing and reliably accessing all the infromation is a daunting task, and you are not always going to have the time to do that. But this wasn’t my only problem, and not even my biggest one. The biggest problem of them all for me was that I had to prepare, have somewhere already or improvise on the spot a new kind of representation of the topic on hand, depending who I was talking to. But this is natural, we have all encountered this phenomenon, each stakeholder has different levels of expectations, other aspects are focused from different perspectives. What is important, however, is that regardless of the point of view, different levels of expectations actually all target the same expectation for a given topic, but different roles require different granularity. They say a picture worth a thousand words, but if you have to come up with the same idea on five different levels, and you need five different pictures for that, that’s a few thousand words too many.

‘I see’ we used to say to confirm that we understand something. We feel the way our brain is working instinctively. Our mind compiles pictures to represent situations, events, people, even in case of auditory information processing. I was a curious child I wanted to know how everything works so I dismounted gadgets to see it. It took years until I learnt to rig up them again. I liked stories very much. If somebody came to our home I grabbed their hand and lead them to my books and asked them to read a fairy-tale. And an additional one. Then I drew stories. I drew a lot. Later I learnt to write and I wrote stories. During my school years I took notes. I wrote and draw continuously. Thus I practiced analyzing, synthesizing and visualization. Visualization is the most important element of my learning style. That’s why I’m enthusiastic with our project. My vision is to create a tool, methodology and platform that will enhance and support project management, planning, decision-making and problem solving processes by providing insight, change of point of view and perspective. In the future we could implement solutions for inclusion of the emotional component of our thinking and we will able to model the actual way of our thinking in the end.

I come from the Software Development industry, and in the last several year I work closely with developers, architects, product people and management. If you work with people from different departments and levels, you usually have to adjust what you are saying. For example for top management, you only need to describe the big picture, the important tradeoffs and the value proposal, and product-oriented members are usually not that interested in the tech details. However, a developer needs the implementation details and core logic behind it, and not necessary the whole architecture. If you want to destroy these barriers, you have to have a multi-level description that can be touched anytime. Also, if you work in a multi-cultural environment, you often would find that minor differences in sentences could have huge impacts - and the best common language you could use is drawing. This is where I was first touched by this idea, if you could draw on multiple layers, you could present this drawing to different departments and levels, hiding those details that are not interesting for the given audience, but also letting them know that it is either part of a bigger picture, or that this is not all the details you have. This should increase teamwork and getting involved, everyone could understand better where are they in the picture. Also, I know several people who are trying to do TDD/BDD, and if I sit down with them describing the details, it always ends up with compromises, and not real TDD. It looks like to me, these concepts works well as an idea, but they are hard to implement. The flaw I usually find is these processes are too rigid, they are either burning efforts since the tests and acceptance criteria should be defined by multiple people (product, dev, and QA), or they are not detailed enough. But if you say that the product expectations could be clearly defined (by the PO/PM), which could be derived to exact tests/behaviours/expectation by the QA, and the HOW is being done by the dev, it would be more agile, more organic. Nonetheless if you could really wire in these concepts or flows to not just real code, but real products, and monitor their behaviour there, you could analyise the bottlenecks, investigate given scenarios or just simply collect data to your next steps, that would be awesome. My expectation was to create a great product that would help me describe the product we are creating in any stage, for any member I need to collaborate with. My current expectation is much more - I want Expectide to exceed that and help everyone who has a complex process define, analyse and optimise it.