Design specification for the interface

In this article:

• What is a design specification

• Types of Design Specifications

• Step by step creation

• Conclusion

What is a design specification

Surely every designer has faced the need to call 10 times a day, explaining to colleagues how things work. It happened even after implementation. Sometimes such communication can lead to numerous edits and clarifications in layouts, and sometimes even to a change in functionality.

There is a tool that will help make the process of transferring layouts to development much more efficient, reduce the number of calls and synchronize the vision of the interface in the team. We call it a layout specification (sorry, analysts) or a “design specification” (for some it may be familiar as functional interface specification). Do not confuse with technical specifications and analytical specifications.

Definition
A design specification/layout specification is an explanation of the operation of interface elements and significant parameters in the layout, fixing the limitations of the system, as well as the rules for the behavior of elements during user actions and when the system responds.
A design specification is not limited to just a set of rules, but also serves as a tool for communication and recording agreements within the team. While developing the interface, the designer interacts with an analyst, tester, UX writer, product owner, and developers. All participants influence the final result, and important points are recorded in the specification.

In this article, I'll describe how to create a design specification in product development, when to call a developer, and how to connect with colleagues. After reading, you will be able to create cool specs.
Working tool – Figma.

Types of Design Specifications

On the Internet you can find the following artifacts, close to or included in the concept of “specifications”:

• Mock-up screens showing close-up states of the system, sometimes with small captions

• Call and verbally explain to the developer “how it works” (verbal specification)

• Sequence of screens representing the user journey

• Interactive prototypes

• Accompanying multi-page text documents

• Mix of all of the above

We in the team also used similar artifacts, and then came to this combination:

1. A small list of screens (close-up interface to demonstrate the placement of designed elements or an adaptive layout of the entire page)

2. Main user path with screens, if important

3. A document listing the page elements and explaining how they work

All this is included in our concept of design specifications. And, since the specification is a communication tool, it is accompanied by some organizational processes. For example, we have several “acceptances”, during which we demonstrate mock-ups to colleagues and verbally convey the specification, adding to it as the demonstration progresses.

Let's now look at another classification. According to NNGroup There are three types of specifications:

1. Specification of elements

2. Functional Specification

3. Content specification

In SimpleOne, products are developed according to a single design system, which describes the basic components, fonts and styles, so further I will only partially mention the “specifications of elements”. Let's focus on the two remaining types as defined by NNGroup: “functional” and “content” specifications.

A functional specification focuses on how the interface and systems should work. The content specification contains explanations for the content itself: messages, illustrations.

Step-by-step creation of a specification

By the time of the first acceptance, the design specification should already be ready.

Previously we used text and pointers to create a specification, also a plugin DesignDoc [Spectral]now switched to Annotations for Dev Mode.

In the process of creating a specification, we indicate all the components step by step functional specification:

1. Default interface state

2. Target state (after user interaction with the system)

3. Result of interaction in the target scenario

4. Corner cases (edge ​​cases) before/after interaction with the system

5. Display in different parts of the system (if applicable)

6. Display on different resolutions/devices (responsive, web, mobile)

7. Load states (if relevant)

Let's go through each step using the example of the warehouse interface for ITAM product.

Step 1. Default state of the interface

Here it is important to describe all the elements that are in the developed interface / on the screen.

If a new component was created, indicate all its states. Show hints (tooltips), label what happens when you click on a button, what opens in a new tab, and what in the current one. Don't confuse the cursors: the type of cursor is also customizable by the developer.

Item specification will automatically appear in the figma interface, but sometimes it’s a good idea to indicate important details through the Annotation tool.

Step 2. Target Interface State

Label the items that changed and why. If there are new ones, please indicate them as well.

Step 3. Final result after interaction

As in step 2, label the new states of the previously mentioned elements. If some user actions are limited or, conversely, new opportunities appear, please also indicate. For example, in my screenshot you cannot change the amount of the reserve, but you can first cancel the reserve for all assets.

Step 4: Edge Cases

Display the states of elements for which changes are possible in non-target scenarios – corner cases. Ask yourself: what if there was more content here? Or will it not happen at all? Also work through scenarios with errors.

Step 5. Display in different parts of the system

If your interface looks different for different users, or perhaps needs to appear in different styles, show what it would look like. In our case this was not necessary.

Step 6: Display on Various Devices

SimpleOne is a responsive web interface. Therefore, I have indicated how elements are shifted/hidden when the window width is reduced and how it looks on mobile resolutions.

The Measure tool can be used to mark important distances that the developer should pay attention to when developing an adaptive design.

After completing all the steps, add a prototype; if you plan to animate something, specify the animation code – it can be pulled out from the figma itself. It’s better to focus on it, because… It can be quite difficult for a developer to find an animated layer to view the code.

Content Specification

We do not isolate the content specification separately as a type, but rather work it out together with the interface states within the functional specification. Icons are reviewed by designers, and texts are edited by technical writers who serve as UX writers on the team. We try to make texts easy to read and user-friendly, thus creating a draft for colleagues.

After working out the design specifications

When the specification is ready, we arrange the acceptance of the prototypes with colleagues: developers, product owner, technical writers, testers. At the acceptance stage, we check with the developer whether everything is clear to him or whether there is something additional that needs to be specified.

Everything is in one place with the necessary details, but it really helps you focus.

— Nikita Mironov, Lead Development Engineer at SimpleOne

The process of creating a specification can be accelerated: if the UC (usage scenarios) with the list of corner cases have been worked out and agreed upon before the layouts, all that remains is to transfer the description to the layouts for specific elements and add the missing ones.

Conclusion

The specification helps the designer to double-check himself and reduce possible calls and sudden development of solutions to “forgotten” states.

The design specification really helps me and the whole team. Up to 90% of issues are resolved without unnecessary calls.

Ananyan Karen, UX/UI designer at SimpleOne

It also helps the entire team: the tester will use it to draw up test cases and check if defects arise, the UX writer will need it to quickly understand the context for correcting texts, and the product owner will help make sure that he is satisfied with the final result and the assumptions made due to development limitations.

Visually it is easier to understand what functionality is being added and what is being adjusted.

— Stanislav Labensky, QA engineer at SimpleOne

But, like all the tools in our work, the structure of the specification is not constant: we collect feedback from colleagues, learn about new tools and approaches, thereby complementing and improving it. The specification remains a valuable tool for us to help us communicate, understand, and track changes to designs.

How do you fix the rules for the interface? Share in the comments.