There are situations when development has already started, the budget has been allocated, and as a result, the deadlines have shifted and the result of the project is not what was expected. In most of these cases, the root of the problem lies in the terms of reference. More precisely, in its absence or too general, blurred content.
A technical specification for creating an application or website is like an anchor in a project, which helps to avoid ambiguities and secures disputes.
Simply put, a technical specification for creating a website and application is a conversation between the customer and the designer, only recorded on paper. The terms of reference help both parties to understand exactly who is doing what, when, and for what money. And if one of the parties wants to "replay" in the process, there will be something to rely on.
The scope of the TK can be any. For some, one page is enough, but somewhere 50 is not the limit. The main thing is to make it clear.
Imagine that you ordered the printing of an outdoor banner. The layout looked great on the screen: bright, clear, with perfect layout. But when printing, it turned out that the logo was blurred, the font was barely readable, and the picture was stretched. Why did this happen? Because you didn't specify the technical parameters: dimensions in centimeters, resolution (dpi), crop zones.
In development, everything works according to the same principle. You can be inspired by a successful product, assemble a team and start the process. But if you don't fix the details — the type of authorization, business logic, behavior of the elements, platforms - at some point the deadlines, budget, and even the very essence of the project will "go".
The terms of reference are like a real—size layout. It allows you to see a project before it starts living its own life — with bugs, improvements, and a growing budget.
In the TOR, you can see why the project is being done, for whom, with what restrictions and conditions, what forces and technologies, and what should happen in the final.
Without this document, you can discuss "beautiful/ugly" for a long time, but you can't build anything that works.
| The TK section | What to include | Why is this necessary? |
| Customer Overview | Who is the customer, what does he do, industry, business features | It helps to understand the context of the project and delve deeper into the values of the brand. |
| Field of work | What exactly is being done: redesign, from scratch, interface, functionality | To avoid "blurred" volume and constant expansion of tasks |
| Target audience | Age, gender, interests, where they live, whether they are familiar with the brand, what problems they solve | To make a product for people |
| Competitors | Who is on the market, what is the difference between the product, SWOT analysis | It gives you an understanding of how to stand out, as well as helps you find gaps in the market. |
| Project objectives | What we want to achieve: increase conversion, simplify UX, expand reach | All decisions should be checked for compliance with these goals. |
| Inventory | Logo, fonts, colors, guides, brandbook, existing materials | In order not to waste time on what is already there, and not to go against the current style. |
| Deadlines | Dates by stages: prototype, mock-up, test, launch | Helps to manage expectations and plan resource usage |
| Budget | Estimate by stages, number of edits, paid additional work, reserve | Removes "surprises" during the project and reduces the risk of conflict |
| A brief summary | A page with a summary of all the points | It is convenient for approval, final approval and as a navigator in the process. |
At first glance, the request is reasonable. If there is a reference, it means that you can quickly estimate the volume and budget. But in practice, this is not the case at all.
Large services are complex systems where many things are connected, such as business logic, monetization, and user behavior. Even in the familiar interface, there are dozens of solutions that are not visible on the surface.:
How does registration work? Via email, social media, or by phone number?
How does the personal account work? Are there notifications, filters, action history?
What monetization models are in place? Subscription, one-time payments, commission?
Is there an admin panel? And moderation? And the analytics system?
Which technology stack will we use?
Will there be an adaptive or native mobile app?
Each of these points affects the architecture, timing, and cost. And also — for the success of the project as a whole.
One of the main myths is that if a competitor's interface looks simple, then development will be simple. In fact, this is the result of a lot of hard work: analysis, fine tuning, and a well-developed technical specification.
Usually, the technical specification for the development is created by the joint efforts of the client and the contractor. The more actively the customer participates at the start, the higher the accuracy of the final document.
If you want to save time and immediately receive high-quality technical specifications for a website or application suitable for the entire team, then we have a service for creating technical specifications. And if you also need a project implementation, then we can develop custom software.
Here are the main questions for creating clear product documentation.:
What kind of result do you want to get?
What are the specifics of a business or a field?
How is monetization planned?
What budget and deadlines do you have?
Which platforms are prioritized?
Who will implement and maintain the product?
The customer can independently write a technical specification for the creation of a website if the project is very simple, has experience in development and full confidence in the team. In other cases, it is better to involve specialists.
Usually involved in the preparation of TK:
A marketer analyzes the target audience and sets business goals.
The designer formulates the requirements for the interface.
Developer — describes the architecture, API, and limitations.
Technical writer — collects everything into a single, understandable document.
If you assemble such a team of independent specialists, it is long and expensive. It is more convenient to delegate a task to a contractor.
Without a technical specification for the website or application, the project works like a broken phone. That is, the team acts on the basis of assumptions, not facts. Someone presents the interface one at a time, someone - in a different way. Developers lay down one logic, designers draw another, and the customer ends up getting something different from what he expected.
You can think of a thousand reasons why TK is needed, but there are two main ones. The first is about efficiency, so that the team understands exactly what to do and doesn't waste time guessing. The second is a guideline that helps you keep your focus and stay on course, even if the project gets more complicated over time.
Yes. The terms of reference for the development of a mobile application helps to fix the requirements for functionality, design and deadlines so that the development team accurately understands the task and implements it without modifications and unnecessary costs.
