Development of a personal data verification service

OMION is a service that helps people understand which Internet resources contain their personal data.

At the same time, the project’s task was initially much broader than creating a regular website. It was necessary to develop a full-fledged digital product with its own logic of operation, tariffs, payment, personal account, verification system and the formation of final reports.

The user had to go through the entire scenario inside one service:

select a tariff → pay → specify data → run verification → wait for results → study the information found → receive instructions → download the report.

LP Agency was almost entirely responsible for the development of this product, from research and visual concept to frontend, backend and integration with the automated verification system.

Before the full-fledged design, we conducted a study of the target audience.

This was already a study of the product itself, and not just a formal stage before development.

The study examined how potential users perceive the idea of the service, how interested they are in the problem of searching for personal information on the Internet, how they perceive such a product, and which visual communication inspires more trust.

22 respondents took part in the survey.

Separate research questions were devoted to the perception of the product, the Internet habits of users, their level of knowledge and attitude to online advertising.

The visual presentation was also tested: participants were offered options for advertising materials and found out which ones were perceived better and why.

This allowed us to obtain not only a technical description of the future service, but also an additional understanding of its audience.

The next stage was the design of OMION itself.

We have developed:

• logo;
• brand colors;
• the font system;
• UX scenarios;
• prototypes;
• UI design;
• UI Kit;
• page structure;
• personal account interface;
• interfaces of the verification process;
• interface for displaying results.

In other words, the design was created not around an existing corporate website, but around a digital service that a person was supposed to use.

This has significantly influenced the approach to the interface.

It was necessary to explain to the user a rather complicated technical process in simple language: what exactly is happening now, how long it is left to wait, what data has been checked and what each result means.

One of the main technical parts of the project was the automatic verification system.

About 150 Python parsers were developed for the project.

Each parser was focused on a specific service or resource.

That is, instead of one universal mechanism, a system of specialized handlers was built.:

OMION → specific parser → verification of a specific resource → result → general results system.

For example, one handler could be responsible for checking one service, and another for checking another.

At the same time, the end user did not have to figure out exactly how many internal processes were going on during the check. All the results were collected back into a single interface.

It was this part that turned OMION from a regular website with a form into a real automated service.

OMION was created as a commercial service, so the tariff system became one of the parts of the project.

Three tariffs were implemented.

The user selected the appropriate option, made the payment, and received a certain number of available checks.

After that, information about the available number of checks was displayed in the personal account.

Thus, the tariff system was directly related to the basic logic of the product.:

tariff → payment → available number of checks → usage of checks → balance in the personal account.

This also meant that it was necessary to take into account the user’s condition not only visually, but also at the server logic level.

A full-fledged personal account of the user was developed separately.

It served as a workspace for the service, not just a page with account information.

In the cabinet, the user could see:

• basic information;
• current pricing plan;
• number of remaining checks;
• the history of previous checks;
• account settings;
• information related to the use of the service.

The history of inspections was of particular importance.

The user could return to the results of previous checks, rather than losing information after completing one work session.

The final information was collected in a single report.

For each verified resource, the user could see the result of the verification and understand whether the relevant information was found.

The screenshot of the report interface, for example, shows:

• name of the service;
• data status;
• information about the service’s affiliation;
• an action for further work with the found data.

An important point: OMION did not automatically delete data from external sites.

If the information was found, the user was provided with instructions explaining how to request deletion on their own.

Thus, the service did not promise the user the impossible, but closed the next logical stage after the information was discovered — it explained what to do next.

On the technical side, the project consisted of several related parts at once.

The main website and server logic were developed in vanilla PHP, without heavy frameworks.

Frontend was also created without using large frontend frameworks — in HTML, CSS, and JavaScript.

A separate Python circuit was responsible for specialized checks.

Conventionally, the architecture can be represented as follows:

User Interface
↓
PHP / basic business logic
↓
tariffs and available checks
↓
the system for launching checks
↓
~150 Python parsers
↓
collecting results
↓
personal account / report
↓
automatic PDF

At the same time, for the user, all this technical design is hidden behind a single interface.

The special feature of OMION is that LP Agency got involved not only at the programming stage.

As part of the project, we have gone through almost the entire path of creating a digital product.:

research → concept → UX → prototyping → UI → branding → UI Kit → frontend → backend → personal account → tariff model → verification system → parsers → results → PDF.

In other words, the customer did not receive a set of individual pages, but an interconnected service.

The most interesting part of the project was the need to combine a large number of independent checks into a single system.

About 150 separate Python parsers were supposed to work as part of a single product.

For the end user, everything should have looked simple.:

entered the data → started the check → received the result.

But behind this simple scenario, there was a complex system of interaction between the main part of the application and specialized handlers.

The second important task was to design the user experience itself.

The user needed to explain a complex topic without overloading with technical details: what exactly is being checked, where the information is found, what the result means, and what actions are available next.

Instead of a standard corporate website, a full-fledged commercial online service was created.

The user could independently go all the way from purchasing the tariff to receiving the verification result, and the customer received a technical platform combining a user interface, a personal account, payment, a verification system, specialized Python handlers and automatic reporting.

At the same time, the project could be further developed: add new verifiable resources, expand tariffs, and change product logic without rebuilding the entire user scenario.

OMION is an example of a project where LP Agency has developed not just a website, but a digital product itself.

We started with audience research and brand creation, designed the user experience, developed the interface, and then implemented the entire technical chain — from payment and personal account to a system of about 150 specialized parsers and automated PDF reports.