Design Thinking Process

7 Guidelines for Zero-Frustration Design-Centric Specs

7 Guidelines for Zero-Frustration Design-Centric Specs

We’ve all been there: your design team innovates at an incredibly fast pace, but engineers are just spinning their wheels unsuccessfully trying to make it work, only to end up with a delayed release of a misaligned product.

In fast, agile environments it might be challenging to perform proper design-development hand-offs and continuously maintain proper quality of the specs without wasting lots of time and only becoming less productive as a whole.

Traditionally, the software system description is stored in a Software Requirement Specification (SRS) document, generally consisting of dozens of pages, line-by-line describing:

  • what the system must do,
  • how it must behave,
  • the properties it must exhibit,
  • the qualities it must possess,
  • and the constraints that the system and its development must satisfy.

This works extremely well in a traditional waterfall enterprise software development environment, but not so well in an innovative, agile team that moves fast.

“In our process, we use our product design team’s visual deliverables as input documentation and requirement specification for the development processes.”

We’ve tweaked this model a bit. In our process, we use our product design team’s visual deliverables as input documentation and requirements specs for the development processes. We’re confident in the core principles conveyed by the visual design deliverables because the designers on the team have already gone through the necessary steps to validate the UI prototypes with key stakeholders and end users. Together with designers, we extend design deliverables by defining edge cases, different application states, and adding a few annotations for clarification. This allows us to use visual design as specification for development.

Here are some of the guidelines our team follows in order to produce deliverables that help boost our efficiency:

1. Include user flows in visual design artifacts: show the flow of all possible cross-screen user interactions.

Users scenarios may be displayed in visual design as scenario maps.


2. Include a comprehensive set of all possible screen or element states in the application.

Our team follows the guideline of 9 States of Design:

  • Nothing – the component is not initialized;
  • Loading – data has been requested from data sources and is loading;
  • None – no data has loaded or been added, the component is empty;
  • One – there is only one item in a list, or on the screen;
  • Some – typical state of a component, it has some data;
  • Too many – too many results or data is very big for this component;
  • Incorrect – incorrect state after validation, wrong data;
  • Correct – correct state after validation;
  • Done – operation is finished, Item is selected, etc.


3. Include notes and comments.

Short annotations may describe non-trivial behavior in the design that may be difficult for developers to understand from the set of static screens.


4. Provide dynamic prototypes for animations and transitions.

Sharing dynamic prototypes for interactions and transitions helps us to show duration, speed of transition, and other important attributes directly from the prototype. Most often, we use Principle for this.

5. Add error states.

The real world is not ideal and errors occasionally occur. Our design documents contain different cases to show error states.

  • Not loaded – no internet connection or there is no access to data sources.
  • Data corrupted – required data is missing or data structure is invalid.
  • Unexpected error – internal issue, application failure.


6. Keep the visual design artifacts up-to-date.

Requirements should never be out-of-date. So if anything on the project gets a visual or logic update, we update the design team deliverables.

7. Demonstrate all updates and changes to the team.

All developers should know about updates and work only using final, up-to-date information. A regular cadence of meetings or checkpoints, where designers demonstrate their updates, helps significantly.

This approach has proven to work well on products that have a lot of screens and UI features, as long as the business logic is relatively simple. For more complex products with a lot of business rules on the front-end, we create additional documents describing the requirements and business logic.

Using UI design as a specification for developers helps us keep all needed documentation in one place and updated in a timely manner. Because responsibility for making updates rests with one person – the UI designer – any engineer can easily find the latest version in the repository, review it, ask questions and create awesome products.

While preparing design documents, our design and engineering teams collaborate closely and, together, can achieve amazing results. Great teamwork allows us to accelerate the development process, understand each other more completely, and make successful digital experiences.

Other Journals