My Journey to formspace.design: When Programmers Didn't Understand Me

Throughout my long entrepreneurial career, I often encountered the same problem: how to explain what I needed to a programmer and get exactly that, rather than something similar but utterly useless for my business. These were years of trial and error, frustrations, and wasted resources, which ultimately led me to create formspace.design. I realized that the best way to get the perfect tool was to build it myself, drawing on my unique experience.

The Beginning: How I Realized Automation Was Needed

My history of interacting with developers began back in the 90s when I was Deputy Director at NPF Alkar. Among other things, my task was to set tasks for programmers regarding management accounting. Even then, I felt how difficult it was to translate intuitive business processes into the strict language of code. What seemed like a simple task – automating reporting or inventory management – turned into long explanations that rarely led to the expected outcome.

Later, managing the company Dom i Sad from 2000 to 2022, I continued to seek automation methods. We tried implementing various CRM systems, but each required adaptation, and explaining my needs to external developers repeatedly hit a wall of misunderstanding. I described these difficulties in detail in the article “Years Without Proper Management Accounting at Dom i Sad: What It Led To”. It was a vicious cycle: I spent time on explanations, money on refinements, and ultimately received a product that only partially solved problems, or even created new complexities.

The Translation Problem: Business Language vs. Technical Language

The main problem lies in the difference in mindset. An entrepreneur thinks in terms of results, efficiency, and customer experience. My vision of a landscape project is a holistic picture where every detail has its meaning, where there is room for creativity and flexibility. A programmer, however, thinks in algorithms, clear rules, and logical operations. For them, unambiguousness and predictability are important. When I say, 'I need the estimate to be calculated quickly and conveniently,' I imply that the system should consider many factors: plot area (e.g., 10 or 15 ares), type of work (laying roll lawn, planting trees), chosen materials, terrain complexity (coefficient from 1.0 to 1.5). The programmer, however, will hear 'make a 'calculate estimate' button' and will await a detailed formula for each element, not always understanding the context.

Typical Mistakes in Task Setting

Over the years, I've identified several typical mistakes I made myself and observed in others:

1. Insufficient detail. Vague phrases like "make it convenient" or "make it beautiful" convey no information to the developer. They need specific use cases.
2. Changing requirements on the fly. Business is dynamic, and changes are inevitable. But every such change without clear documentation and revision of the technical specification leads to chaos and additional costs. Sometimes we would spend 2-3 months training employees to work with a new CRM, only to realize it wasn't suitable due to constantly changing requirements.
3. Lack of clear use scenarios. I couldn't always envision all possible situations in which the program would be used. The absence of "user stories" led to the system not working in real-world conditions.
4. Expecting the programmer to "figure it out themselves." This is perhaps the most common mistake. A programmer is not an expert in your industry. They shouldn't have to "guess" the implicit nuances of landscape design or project management. My task was to clearly articulate these nuances.
5. Focusing on "how to do it" rather than "what should be achieved." Sometimes I delved too deeply into technical details, trying to suggest how to implement a particular function, instead of clearly describing the desired end result and business value.

How to Learn to Speak with Programmers

My experience taught me several important rules:

• Write the technical specification (TS) in maximum detail. This should not just be a list of functions, but a description of business processes, user scenarios, examples of input and expected output data. The more specific, the less room for interpretation.
• Use prototypes and mockups. Even a hand-drawn interface sketch, screenshots, or simple Figma prototypes can say more than a thousand words. They allow you to visualize the future product and identify misunderstandings early on.
• Break down tasks into small, measurable steps. Instead of one large task "build a CRM," it's better to set 10-20 smaller ones: "implement client addition," "create a date filter," "configure notification sending." This allows for process control and course correction.
• Focus on business processes and the desired outcome. Always start with the questions: "What user or business problem does this solve?" and "What specific result do we want to achieve?".
• Provide concrete examples. If a function needs to calculate something, provide examples with numbers. If it needs to process data, show what that data looks like.

Consequences of Ineffective Communication

Ineffective interaction with developers always led to regrettable consequences. Firstly, it was a waste of time and money. Projects dragged on, budgets swelled, and we still ended up with "not what we wanted." Secondly, it caused frustration and decreased team motivation. When employees see that automation efforts bear no fruit, their enthusiasm wanes. I recall instances where, after several months of implementation and training, we still couldn't fully launch a system because it turned out to be too cumbersome or didn't account for the specifics of our processes, such as the peculiarities of accounting for materials for landscape work or planning irrigation for a 20-are plot.

Despair and the Birth of formspace.design

At some point, I realized: to get a tool that perfectly matched my needs, I had to create it myself. To me, a person who was 61 at the time and had never been a professional programmer, this seemed insane. But years of frustration and the desire to create something truly useful for the landscape industry outweighed that. I started learning programming with the help of AI, and this opened up entirely new possibilities for me. I described this journey in the article “How I, a Former Marketing Expert, Design formspace.design”. Thus, formspace.design was born — a platform created by a landscape specialist for landscape specialists, where intuition and creativity do not encounter the barriers of technical language.

How to Plan in formspace.design

formspace.design is a direct answer to the communication problem between designer and programmer. It's a tool that allows you, as a landscape design specialist, to directly embody your ideas, bypassing the need to translate them into technical language. I built it to be intuitively understandable and as close as possible to the actual stages of working on a project.

Imagine you need to plan an 18-are plot. You start with Module 1.0 "Plot Plan", where you easily set boundaries, mark existing structures and utilities. Then you move to Module 1.1 "Zones" to intuitively delineate functional areas: for example, a 4x5 meter barbecue area, a 6x6 meter playground, a vegetable garden, a relaxation area. You see all of this immediately, visually, without having to explain your ideas to anyone.

If you have a general idea but lack specific concepts, use Module 2.1 "AI Concept". You can upload a photo of the plot or even just a mood board, describe your preferences – for example, "a modern minimalist garden with an emphasis on evergreen plants and a pond" – and artificial intelligence will generate several concept options. For more detailed visualization of specific elements, Module 3.1 "Design by Photo" allows you to upload a picture of an existing place and "try on" various design elements: change paving, add shrubs, alter the house facade color. All of this happens in real-time, and you immediately see the result, without lengthy correspondence and revisions, which are inevitable when working with external contractors. This allows you to focus on creativity, rather than the technical details of task setting.

FAQ

Why is it so difficult to explain business processes to a programmer?

Business processes are often unformalized, contain many exceptions, and depend on human factors or intuitive decisions. A programmer, however, thinks strictly logically, requiring clear algorithms and rules for every situation. This fundamental difference in approach and the lack of shared context create the main communication barrier.

What are the main mistakes entrepreneurs make when ordering software?

Most often, this is expressed in the absence of a detailed technical specification, unclear acceptance criteria, and constant changes in requirements during development without proper documentation. Many also expect the developer to guess the implicit nuances of their business, which leads to significant misunderstandings and the need for costly rework.

How to avoid the "got the wrong thing" situation?

Start with prototyping: even a simple sketch or mockup will help visualize the future product and identify discrepancies. Break down the task into small, iterative stages with regular checks of the results. It's important to focus on what the system should do and what value it should bring, rather than how it will be technically implemented.

Do you need a technical background to set tasks for programmers?

You don't necessarily need to be a programmer, but understanding the basics of how programs work and being able to think systematically significantly simplifies the process. Develop skills in structuring information and formulating requirements as clearly as possible, using concrete examples and use cases to minimize ambiguity.

What to do if a project is already going wrong?

Immediately stop and conduct a retrospective with the team to clearly determine what went wrong and why. Review the technical specification; perhaps break down the remaining work into smaller, more manageable tasks. Sometimes it's better to stop a project and start from scratch or change contractors than to continue investing in a doomed direction.

Why does formspace.design solve this problem for landscape designers?

formspace.design was created by me, someone from the landscape industry who personally encountered this problem. I built a tool that is intuitively understandable to designers, allowing them to directly embody their ideas without having to translate them into technical language for programmers. This eliminates the intermediary and minimizes the risks of misunderstanding, ensuring accuracy and speed in realizing the vision.

What specific steps helped me transition from "explaining" to "creating"?

The key was realizing that no one would understand my unique vision as well as I would. I began actively exploring the capabilities of modern technologies, particularly AI, for automating development. This allowed me, without being a professional programmer, to start creating formspace.design, drawing on my vast experience in landscape design and business. It was a transition from trying to make others understand to independently realizing my idea.

My journey to formspace.design is a story of how years of experience and encountering recurring problems can become a powerful impetus for creation. If you too are tired of misunderstandings and want to focus on creativity rather than explanations, try formspace.design. I am confident you will appreciate the difference when a tool speaks your language.