Interface redesign and update of the system design for Smart Housing and Communal Services

Client

Smart Housing and Communal Services is a platform for developers, management companies, residents and providers of housing and communal services. The platform combines information on the housing and utilities sector within one system; owners, administrators and suppliers each have their own personal account as a separate user category.

The objective

We have known the Smart Housing and Utilities Project team for a long time. After launching a pilot project for several management companies, the backlog of the product began to expand. Along with the new features, the Smart Housing and Utilities team decided to update the visual part.

The project consisted of two parts: redesigning the interface of the administrative panel and developing a redesigned mobile app on a tight schedule and with limited budget. In this case study we'll talk about updating the design system, developing new web office templates, and classifying the patterns of working with the client.


Website admin

We have solved similar tasks before: for example, we developed interfaces for the real estate portal "Where's the Housing Company?" and CPA-platform "Where is the Elephant?", designed the interface for the service of advertisers and web-developers ADVgame.

Course of work

We started with onboarding — the client gave our team a guided tour of the platform. The product manager outlined the problematic areas of the existing solution and told us what features are present in the development plan for the product in the near future, so we could design keeping them in mind. We thank him for the detailed answers to our questions about working in the admin panel. 

Together with the client we chose the Google Material design system. This system has an implementation for frontend frameworks, and the component base allows the designer to work on designing the user experience and solving specific problems instead of coming up with individual ui-elements. Moreover, Google Material has some basic ready-to-use content patterns, and we applied some of them as well. As a result, we reduced the development time, which was important for the client.

This is what the web office design system looks like

Web office design system

According to the client’s data, users more often use the application screens — creation of a new application, its further progress in the course of execution and a list of all applications. The application interface itself also needed to be made more compact to simplify the dispatcher's work.

We worked out the basic patterns of using the Personal Account on these structurally complex screens: how the editing modes work, how to use filters. Convenient filtering on the application screen is in high demand because of the large amount of information provided and the requirement for a high speed of finding it — the dispatcher often needs to find information on the application while talking to the owner. Cumbersome filtering in the table slowed down the work and required changes. Even in redesigned form in individual filters — 9-10 items vs. 15 or more that had existed originally. 

This is an example of the operator's personal account before and after the redesign. 

The Applications section before and after

arrow-compare-left.svg arrow-compare-right.svg

The New application section before and after

arrow-compare-left.svg arrow-compare-right.svg

The Personal meters section before and after

arrow-compare-left.svg arrow-compare-right.svg

We exposed the filtering hidden inside the buttons on some pages. During the development we didn’t only rearrange the filtering system, but also made it more compact and uniform for the entire platform — in the future when adding new screens the client will be able to combine all filters by creating templates.

Filters before and after redesign

arrow-compare-left.svg arrow-compare-right.svg

Working with individual pages

We spent a lot of time typing the admin pages. We marked out the table variations: they are numerous in such rich interfaces and they are difficult to comprehend. We redesigned the main tables, such as lists of houses, owners, applications, calls, notifications, and meters. In order to do this, we grouped repetitive entities, refined categories and partially changed inputs and moved secondary information away into tooltips. We brought all tables to the same styling — the only things that change are the set of columns and function keys. The time needed to find the necessary information decreased, and it became easier to perceive it. The client will be able to rebuild the remaining tables, as well as the newly introduced ones, on their own using ready-made templates — we did not undertake this task because of the time and budget limits.

Below you can see some of the interface pages before and after the redesign. 

The House list page before and after

arrow-compare-left.svg arrow-compare-right.svg

The List of owners page before and after

arrow-compare-left.svg arrow-compare-right.svg

The Notification list page before and after

arrow-compare-left.svg arrow-compare-right.svg


This is how the process of developing the tables went.

Working with tables
Table with actions on the pages List of charges and List of houses
Table with the actions on the pages List of owners and List of notifications

Together with the client we also agreed on how to make unique pages and complex design components: building plan, updated entity pages with many fields.

Below you can see what the building plan settings looked like before.

Adjusting the building plan + our train of thought

This is what the building plan looks like after the redesign. 

Settings of the building plan
Building plan of an object

The client also asked us to tidy up the modal windows which were fragmented and unstructured. In order to solve this issue we developed an algorithm: we described what information is displayed on the page, and what information is sent to the modal.


Working with modals

And here's a page about consistency: for the HTML-programmer, the designer, and others interested.

Design consistency

Limits

The design concept set technological limitations — it was regular front-end, that is, the client could not do front-end on reactive frameworks. It was also necessary to take into account the users’ conservatism — most of the dispatchers are elderly people who have been working with the existing solution for a long time. It was important that the employees could quickly get used to the updated interface after a short onboarding.

The result

The design of the admin panel was successfully updated, and we met the tight deadline. The client was doing the upgrade of the design and working at the same time.  The entire project from the start of the design to the code took 5 months. The dispatcher’s personal account became more convenient, and the administrators quickly got used to the new interface.

Users noted not only the aesthetics of the tables, but also the usability. The client gathered a group of volunteers and tested each screen, all filters, and buttons. As a result, the interface became convenient partly owing to the users’ feedback.

Time costs

200 hours.

 

Project team

  • Vsevolod

    Project manager

  • Ekaterina

    Designer

  • Artyom

    Lead designer

  • Vladislav

    Designer

  • Vlad

    Designer

  • Anatolii

    Client side project manager

Next project

Let's discuss your project

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.