Deepki - Collection monitoring board
Monitoring data collection of real estate assets and streams in Deepki's web app
2022 - 2023
Scope of work
UX - UI - User Interviews & Testing
Tools used
Figma, Notion, Basecamp
Deepki is a French company offering an ESG data platform to help commercial real estate investors, owners and managers improve the ESG performance of their real estate assets. The scaleup company helps other businesses to optimize their energy usage, reduce their costs and carbon emissions. 

As a Product Designer, I worked within the product team in close collaboration with the product manager and the engineering team to deliver and design a new feature that aims to facilitate the monitoring of data collection on real estate assets within the Deepki app.
The Problem
Asset and ESG Managers as well as users accountable for data collection want to monitor the progression of data collection on buildings or real estate assets under their supervision.

Today these users have a limited amount of tools at their disposal to do so and rely mainly on their Deepki touchpoints to produce material and reports related to data collection on a regular basis.
Discovery Workshops
Two workshops were conducted with multiple team representatives and head of departments of Deepki. The first workshop consisted of interviewing stakeholders. The stakeholders helped me gain a deeper understanding of the needs and goals of the users. They also clarified business constraints that impacted my design decisions.
Asset and ESG Managers as well as users accountable for data collection want to monitor the progression of data collection on buildings under their supervision.

Today these users have a limited amount of tools at their disposal to do so and rely mainly on their Deepki touchpoints to produce material and reports related to data collection on a regular basis.
User needs
Project management and Progress evolution In order to effectively manage data collection projects, asset managers and data collection users require specialized tools that can simplify the process. Specifically, they need tools that can monitor the progress of data collection, track it over time, and identify any gaps that need to be filled. This includes the ability to quickly and easily access information on who needs to be contacted in order to address any issues or gaps that arise. By having access to these tools, managers and users can more effectively manage their data collection efforts.
During the ideation phase, I started conceptualizing the new feature, sketching how it would look like and function. I started out by exploring two design possibilities with different layouts for this new feature: A card layout and a data table layout. Making two versions of a design was beneficial because it allowed me to compare and evaluate the effectiveness of two different design options. It also made me gain insights into how users interacted with the design in user testing sessions.
Wireframes - Card Version
In this version, users have cards displayed vertically. Each card gives the user an overview of the data collected in a category of their real estate assets. ‍‍ This design allows for a visually appealing presentation of information, which can help attract and retain users as well as having an organized layout to improve the overall usability of the feature. It does have some drawbacks, due to their compact size, cards may not be able to display as much information as a traditional data table or list, which can cause scalability problems. There is also an increased cognitive load on the user; since cards are presented individually, users may need to spend more time processing information and navigating through the feature, leading to an increased cognitive load and time spent.
In this card the user can see the initialized buildings on a chosen scope ( in this case he has grouped the scope on Property Managers ). He has an overview of which property managers are performing well and which others need to continue or start reporting their data. ‍‍
User can group the cards’ content in the scope that he wants. For instance he could choose to group by Country, in which case the first card would show which countries have progressed the most in entering and reporting their data on the initialization of their assets. ‍‍
Wireframes - Table Version
The second version that was thought of was a data table layout, although other members of the product team had envisioned a card layout, I proposed a table version for multiple reasons:

- A table provides a clear and organized display of data, making it easier for users to find and compare information.
- Scalability; a table can handle large amounts of data, allowing users to quickly scan and filter relevant information.
- User control; a table allows for easy sorting, grouping, and filtering of data, giving users more control over how they interact with the information.

It does present a few cons compared to a card layout, a table might be overwhelming for users who are at first, it can also be difficult to design in a way that is both visually appealing and functional. ‍

After having created the wireframes of the two different design layouts, I set up meetings with stakeholders and users to have their thoughts and feedback.
In the table version; each column represents a category where the user and can see the progression of collected data. Each row represents the scope the user has chosen to group by. In this instance he sees a list of Property managers.
User testing
I managed to recruit participants from five different businesses that represented the target audience for which we were designing this feature. I then observed them as they interacted and commented on the two versions of wireframes Through these tests and interviews, I was able to identify pain points, areas of confusion, and opportunities for improvement in the user experience. These insights were invaluable in informing iterative design changes that ultimately improved the overall usability and effectiveness of the product.
‘I prefer the table view, it's clearer and better for exports’
‘I think the table is easier to read, I don't really pay attention to the graphs’
‘The table's a bit overwhelming at first but much more practical, especially to class and filter’
What we learned
The users unanimously preferred the table version to the card layout version. THe continuously explained to us that it was better suited to their needs and would resolve their problems better than other design. We therefore took the decision to discard the card layout and opt for a data table for this feature. We also uncovered pain points and needs that users pointed out for us which we later incorporated into the feature.
We designed the table layout with three main views to meet the  needs of the users.
Asset view

The user has a list of all the assets under his scope with all the information regarding thee assets; their location, their fund and property managers.

With this view he can quickly sort which building has been collecting data, if a building was successfully qualified within the Deepki app as well as the size of the buildings’ floor areas.
Stream view
Users can group by stream or category to see the progress in a chosen scope, this is what we called the 'Stream view'.

The first column will indicate the stream chosen by the user, in which he can see the number of assets, the percentage f thhem having been qualified in the Deepki App.

Essentially giving him a macro view of the dollection of data.
Stream view subpage

Once the user has chosen a stream and would like to see the data gathered within he can click on a row of the table which will bring him to the subpage showing all the buildings and their data.
Design System
Enriching Deepki’s design system

When I joined Deepki, their design system was in its early stages. In order to build more sophisticated interfaces whether it was for this feature or others, I proposed a series of improvements and additions to their current design system.

This included new color variables, more than doubling their spacing variables as well as creating universal components and design molecules such as tooltips, tags and badges or percentage progess bars.
Thanks to the feedback gathered during our meetings with the users, I integrated quite a few changes that they had asked for and were in need of.
Loading animation and states
Skeleton loading states were added either when a column was loading or when the whole table was.
During the user testing, we realized that quite a lot of people weren't familiar with the wording used in Deepki. Tooltips were added to add explainations for users.
Empty search
If a user wanted to search a asset or a stream in the data table that didn't exist, a design was made to indicate that there were no results matching his search.
The final product was a user-friendly datatable. The feature received positive feedback from our users, who reported that it was exactly what they needed. The entirety of the project from conception to launch and implementation took three quarters.