Ginarea trading bot website design

In July 2022, I took on the design of a new version of the Ginarea trading bot management website. This is what the main interface looked like before starting work:

Stage 1: Gathering Functional Requirements

Before starting work, they need to be assessed. To do this, I spoke with the client’s team, asked questions and slowly entered the project, taking notes along the way. After several such conversations, I prepared a document with the functional requirements for the project in Google docs and shared it for all participants to leave comments and agree on the final version.

Functional requirements contain an approximate structure of the future project, a description of user roles, functions that they can use in the system, as well as the timing of creating an interactive prototype and the number of hours that will need to be allocated for negotiations.

The task was simplified by the fact that the logic of the bots was already programmed and the designer did not need to participate in its formation and adjustments. The main task was to update the interfaces so that an inexperienced user could figure out how to set up the bot.

The document is written in simple language so that a non-specialist can understand it. Superficial enough to leave room for design maneuvers, yet detailed enough that one project doesn’t turn into another in the process.

Writing functional requirements for large projects can be evaluated separately, since the designer needs to spend quite a lot of personal time immersing himself in the context. This time the task was not voluminous, so I prepared the functional requirements for free. Plus, the fact that the client’s team promptly answered questions and communicated with me in the same language was taken into account. She also worked in the field of information technology.

Stage 2: interactive prototype in Axure

The design resulted in an interactive prototype with about 50 interconnected screens demonstrating the work of the future new version of the site. This artifact is needed so that all participants in the process can accurately agree among themselves on how everything will look and work. Text descriptions are interpreted by different people in different ways, and an interactive prototype is something as close as possible to a finished project. You can see the prototype here link.

Below are a couple of screenshots:

In the course of work, I successively made three versions of the prototype. New versions were created at the moment when changes were made that significantly transformed part of the previous solution.

Thoroughly worked out the relinking of pages so that you can go through the main user scenarios.

Work on the prototype took a calendar week. Negotiations – about six hours (six sessions per hour). There were no restrictions on edits and comments for the client. The work is structured in such a way that the team moves together towards the goal in short iterations, discussing intermediate results from the first day of work.

First, a navigation solution is created, then the main sections are worked out, then the secondary sections. After that, low-frequency section states are designed (for example, empty lists or error messages) and at the very end, you can create main pages and dashboards – as a result of a complete understanding of the project.

Stage 3: creation of a functional specification

A functional specification (FS) is a document that details an interactive prototype. It pursues several goals at once:

Allows the designer to double-check the result of his work and detail it. When I write a filesystem, I make up to 30% changes to the prototype. Sometimes these are some improvements, and sometimes I just find that I missed something. A detailed text description helps a lot to identify places that have not been worked out in enough detail to be able to give it to developers.
Allows you to describe some things that simply cannot be shown in the prototype. Set limits on form fields and the logic of their work, list system error messages, requirements for loaders, limits on the number of items in displayed lists, and so on. This information allows developers to more accurately estimate the timing and cost of further work on the project.
Over time, when information about how and why a particular section should work disappears from the heads of the project participants, the FS serves as a document that will allow you to restore lost knowledge.

Just like the functional requirements, I wrote the FS in Google docs. Other project participants could follow the progress of the work online and leave comments. But I left most of the comments myself as a designer.

The document took 32 pages, it took no more than a week to create and approve it.

Stage 4: creating a design in Figma

An interactive prototype and a functional specification fell into the hands of my colleague, designer Alexander Shchipakov, and he proceeded to the first stage: the creation of a design concept. To do this, we took one of the pages that visitors will encounter most often (no, this is not the main page): a list of bots.

The first concept proposed to the client did not work. We saw the design and realized that a dark theme is not an option, we need to do it in a light one.

The light concept has come in, we decided to move in this direction. After the concept was approved, Alexander drew all the necessary layouts in the main resolution. And after that, at the very end, I adapted some of them for devices with different screen sizes.

Several layouts to understand the design format of the project. There are some minor differences with the prototype. This happens when a client already sees a “picture”, and not a prototype and a description for it – I want to decide something differently. Most of the time, these are minor edits.