Initial Concept

1st way

Direct calculation

Any feature such as a KPI or a graph can be directly calculated from the dashboard or dedicated page. Clicking on the designated button opens a sidebar, preserving the sense of control by not switching to a different view. In this sidebar, there's a reporting year, which can be changed, and the required widgets. The sidebar also displays the status of widgets.
As multiple features require the same data, I kept the idea from the original concept of displaying all possible results based on the entered data. This way, when the widget is closed, the results for the desired feature, as well as possibly other features, are shown.

2nd way

Exporting a document

Reports are composed of features. Features consist of widgets and, in certain cases, external API calls. Therefore, to complete a report, users only need to complete the required widgets.
With the introduction of custom report templates (see this case study), clients can compose a report with the desired features and get the set of widgets they need to complete. Some widgets are optional, which means that clients can issue a report without completing them. In that case, some data points will be tagged as "unknown" or the dedicated chapter won't be shown.

3rd way

Onboarding

Initially, we had a traditional onboarding process where users would first add a building and its master data, after which they could calculate whatever they wanted. However, we encountered an issue where users often didn’t know what they wanted. Our first idea was to include small hints, like ads for possible options, but with the introduction of estimations (see case study), the minimum required data was reduced to just a few inputs. I then decided to revise and simplify the onboarding process, merging everything into a single streamlined flow where mandatory sections are clearly highlighted, and the rest is optional. At the end of the process, the client receives an initial assessment report and can immediately view some analytics and charts.

The process

The original concept was founded on the idea that many report types share common data. However, it initially overlooked the crucial aspect that the ultimate goal is to create a report or calculate a specific thing. It was crucial to make the process from signing up to getting a report  as smooth as possible. Initially, I emphasized the need to create a separate report processes for each report type, focusing solely on the necessary data for that specific report. After, we could reuse the data already inputted for other reports and display the fulfilment rate of other reports, thereby motivating clients to complete additional reports. This was when the widget concept originated.

In the design process, giving ESG its status as a new field, I heavily relied on information provided by subject matter experts. I combined this expertise with best practices from enterprise software in other domains. Conducting research or competitor analysis was challenging due to the niche size and limited availability of open data. Furthermore, real client user testing was nearly impossible due to the B2B nature and the specifics of real estate sector. As a substitute, I conducted user tests primarily with internal employees, company partners, and subject matter experts. These tests provided insights into product usability but did not fully represent the product's performance in the real-world market.
‍
To address this limitation, we adopted a strategy of initially building features based on assumptions. We then tested these features during sales calls and iterated based on the feedback received. This approach allowed us to refine the product based on real-world interactions and client input.

1st iteration

First assumptions

Initially, the first reports were viewed more as audits rather than exports. Me and a freelance designer collaboratively developed two versions of how the widget could look like. We chose the option that offered easy extensibility, allowing for the inclusion of notes, remarks, and data confirmation, all of which required space.

We operated with this design for a while but soon recognised that the excessive text made it difficult for the client to understand. The requirement for confirmation disrupted the workflow, and clients wanted the ease in manipulating and altering data, and showed no interest in strong error protection. After discussions within the product team and with the management, we decided to simplify the input process and remove data confirmation. During this period, the company's management also realised the potential within the ESG management niche, which led to new feature requests. This prompted the second iteration of widget adaptation to meet evolving needs.

2nd iteration

Making it smaller and simplier

When I received a request to design a dashboard with main KPIs with an option to calculate them directly from the dashboard, I took into account the earlier feedback regarding widget complexity, and shift towards assessment over auditing. It became clear that simplifying the widget to the maximum was essential. I decided to redesign the widget so that it could seamlessly integrate into the sidebar, which was already a familiar element on our platform. This transformation allowed us to enable direct data input from various parts of the software, not limited to the report process. This change turned out to be a game-changer.

3rd iteration

Adding progress check and estimations

The third iteration was primarily focused on the widget content. The concept had proven to be immensely successful, with clients understanding and loving it. However, as widget content was initially quickly developed, some widgets required reworking (which resulted in speeding up an onboarding process from 20 to 8 minutes, see case study).Within the widget concept itself, I introduced a progress bar and estimations for missing or unknown data. Some widgets required multiple inputs to be entered. While the sidebar had previously been used for summary purposes, in this iteration, I added a progress check to pinpoint what data is missing or if there are any issues with it. Estimations were also seamlessly integrated without the need for client to request it. They are integrated in the input fields and can be overwritten if the client has the necessary data.