1) Summary
| Company | ecoligo GmbH |
| Product | Enterprise Resource Planning (ERP) Web App |
| Team | Operations Department → Product Team |
| Roles | Senior Product Designer I; Product Lead |
| Scope | UX, UI, design system; product specifications |
| Tools | Figma, Figjam, Illustrator; Jira |
| Timeline | Sep 2024 - Dec 2025 |
| Overview | I was in charge of rebuilding Ecoligo's ERP (at the design and architecure levels), including the onboarding experience (user sign up, authentication, log in, log out), offboarding experience, and the database pages to manage solar operations, including client registry, contract management, tracking of solar energy measurements, client invoicing based on that tracking, and EPC partner registry, in order to achieve internal user conversion (i.e. discourage external tool usage) while delivering a central operations management tool. |
2) Product and business context
Product overview
Pulse is the ERP system owned by the Product Department, designed to support the Operations Department in its day-to-day activities at ecoligo GmbH. It provides the core services required to record, manage, and archive information throughout the lifecycle of the company's solar energy projects, which are developed and operated by teams across 13 countries in Southeast Asia (SEA), Latin America (LATAM), and Sub-Saharan Africa (SSA).
Pulse serves as the single source of truth for the company's operations. It centralizes client and partner data, supports configurable business workflows while maintaining operational flexibility, and ensures that processes are traceable and compliant with internal and regulatory requirements.
Pulse is designed and operated in compliance with the European Union's General Data Protection Regulation (GDPR).
The challenges
Originally designed by an external software engineering agency in 2018, Pulse (v1) was seen as an internal tool where employees from different departments could record solar project characteristics, but without having strong data correlations, meaning there was no scalability plan in progress to make use of that data other than for visual representation. In other words, they were given a custom version of Excel and Word, where nothing scalable with the data could be done.
It could take up to 10 seconds to display a list of solar projects, which was the main page that all users visited during the day. The system performance was on the ground. This issue made users look for alternatives to Pulse v1 to record their data: MS Word and Excel were the tools to go for contract creation and negotiation and for calculations and reporting of solar asset performance, in addition to Asana, which had the central role for task management.
The lack of connection between data points made the system a wee useless and not scalable. As stated before, the ERP software was designed to collect data but nothing apart from visualising it nicely via dashboards could be done with it. No correlation between finance, contracts, and operations, to put it simply, so it was equivalent to writing data on a text document. Everything needed manual updates. Again, this affected the adoption of Pulse v1.
Pulse v1 was modelled to allow users to have several roles, which sometimes ended up conflicting what they should actually be able to see or edit. For example, some users were supposed to have reading permissions for financial information but because they were listed as admins in the system, they could manage sensitive data. This needed to be urgently fixed.
Pulse v1 was constructed with Java in a monolith approach. This was, according to the new Engineering Team I was working with, not ideal because the data stored was simply too much, there was no real overview of the tables, endpoints, and duplication was unavoidable. There were endpoints under different names doing the same thing, there were different tables storing data for the same service that led to redundancies. Overall, the system wasn't in a great place, and this made the team hesitant to for example, solve bugs. Documentation to refer to? Nil.
This of course represented a challenge. We were a new team set up in Q3 2024 xin charge of building a product from scratch with no prior documentation (either it didn't exist or was severely outdated).
After presenting all relevant points to the Management, they agreed with our approach: We were to build the new Pulse (referred to as Pulse v2) using Python and React using micro-service architecture.
Success metrics
For Q4 in 2024, we set up the following:
• Successful database migration from the Pulse v1 to Pulse v2.
• Release of the production environment with the 5 core micro-services: Users, Projects, Clients, EPC partners, and Central (collecting external country datam for example). Needless to say, this release needed to be bug-free.
System performance increase: From up to 10s requests to maximum 0.2s.
3) Discovery and research
The discovery process was based on all pain points described above, while also validating how the old Pulse was built: Was it really doing what it should be doing for the users?
The primary objective of this phase was to understand:
• Who are the main players in the solar business process?
• What are their tasks? What's the extent of their work without overlapping with other departments, or how do they collaborate?
• What were they expecting to have present in the interface to help them through their day-to-day operations?
• Which devices were used on each stage of the solar business process?
Research inputs
| Source | What was investigated | Key insights |
|---|---|---|
| User interviews (15) | • User journeys • Specific user needs |
• Every user had different needs depending on what department they belonged to: •• Sales Agents were missing a way to standardize contracts with clients because there were different ways to do it depending on the agent and the country where they were closing the deal. They also needed a way to reopen contracts for negotiation. All of this was being done in MS Word and Asana. •• Solar Project Management users were missing a way to register technical information regarding the solar assets: geographical position with coordinates, constructed areas, materials, type of construction, etc.. This was managed in MS Word and Asana as well. •• Asset Managers were missing a way to register insurance policies related to the technical information registered by the Solar Project Managers, as well as registering maintenance visits (scheduled and spontaneous), and a way to link the solar energy produced to report to Finance. This was managed in MS Excel and Asana. •• Finance users were missing a way to automate invoicing based on the solar performance of the assets. The invoicing process was managed in an external tool. • In general, all users expressed that the access permissions were not correctly managed (other departments could see or even manipulate data relevant to their department). |
| User workshops per department | • Bring team members together to be on the same page |
• Departments needed to reassess their processes internally. • Once this happened, implementations in Pulse could happen. • With help of a central process department that needed to be created, the Product Team could get insights on what to implement in a quicker way. |
Key findings
• Because the previous model allowed users to have several roles, conflicts arose. Some users were not supposed to edit and let alone view certain sensitive information in the system. Therefore, the new model needed to feature one-role permissions.
• It was clear that every department interviewed had very specific needs as to what data should be used for, how should it be represented, etc.. We acknowledged all needs separately to visualize how different data points would converge, in order to have a streamlined data flow to avoid redundancies and identify dependencies to create the databases.
• So the problem wasn't primarily that the system didn't provide automation, but that processes were not standardized by department to actually collect the same data. This led to have incomplete or redundant data registered in the system (where most of fields on the different forms were optional). This meant the processes needed to be standardized first, to then reflect them in the implementation on Pulse.
Design principles derived from research
Based on the findings, we established these principles to guide the redesign:
• Chunking: Since some processes within departments were quite complex, the approach agreed with other stakeholders would be to create task-oriented work pieces in the departments' ways of working. This would mean for product design to break complex tasks into smaller steps in order to decrease cognitive load.
• Implement the Doherty threshold for real: Implement a lean, high-performant BE to provide system responses within 400 ms in order to reduce user frustration and perception of a slow system.
• Aesthetic-Usability effect: Develop a visually coherent product aligned to the company branding, without sacrificing usability or accessibility.
These principles became the foundation for evaluating concepts and prioritizing solutions during the design phase.
Significance of this research
The discovery phase shifted the project focus from just rebuilding a new UI for the same backend to solving a broader understanding problem.
Instead of designing the screens cosmetically, the challenge was reframed around:
• Understanding the processes created by the departments, so they could be implemented at the product level. For this, new personas were created and the user journeys were laid out.
• Creating a high-performant product foreseeing the data load generated by all departments in different countries.
• Simplifying all designs to help the users get their tasks done faster, as much as allowed by the processes dictated by the department.
4) Design solutions
In this section, I will focus on the key features that were addressed:
4.1) User management
• Users had overlapping roles due to the possibility to have many - meaning some users had effective reading and editing permissions of information they should not.
Backend:
• The backend needed to be rebuilt as a separate microservice to create a single-role model.
Design and Frontend:
• No constraints.
Different layouts were presented for the Admin role, since only admins would be able to perform user-related actions, like adding users to the system or deactivating or deleting their accounts.
• Variant A was intended to cover the needs of the Admin role. It presented a table with batch action possibilities to deactivate, delete, or edit users.
• Variant B offered a card-based layout, which didn't facilitate the batch actions, but had emphasis on the human side of users, by displaying a larger picture for instance. So users who wanted to know who their colleagues were, for example.
In the end, Variant A won the Admin preference, but the card-based layout was also included as part of the scope of the final solution because it believed to be useful for the non-admin roles (basically everyone else who needed to get "acquainted" with team members in other regions, for example).
I collaborated with the Head of Region EUR, who was in charge of overseeing the standardization of the processes for the rest of the regions where the company was operating, as well as with the Data Lead and the Operations Lead, to corroborate the roles that everyone should be assigned when the system was created.
Here is a short recording of the prototype for Admins, which shows some the toggle between the views and a sneak-peak of the filtering experience.
• Variant B was released with the first version (MVP) of Pulse v2 🚀. Variant A was postponed due to product prioritization - the system didn't have enough users to justify batch actions.
• We got good feedback about the fresher look of the card layout page 😊. On the table layout, even though it was not released with the MVP, it is to be highlighted that during the user tests, admins found it less tedious to execute operations related to users while feeling the table more readable due to the color present in the status chips and the introduction of circular avatars.
4.2) Country data management
• Users were manually entering the same information regarding countries (grid emission factors, VAT and WHT values, or creating contract types that were not legally allowed in certain countries) to countries, financial calculations, project specifications, etc.. This activity was cumbersome and risked the data to have errors. A centralized service (called internally the country service) where all this information could be available was necessary to provide some automation and reliability.
Backend:
• Creating a bunch of API endpoints to connect the country service with specific data points in other services, like projects and invoices.
Design and Frontend:
• None.
Mandatory content blocks
Different mandatory content blocks needed to be considered to build the layout.
Layout proposals
Preamble:
• The access to this screen was located under Preferences, because it contained data points that affected other services.
• The countries would be presented as a table during the first iteration, then the user would click on each row to then access the contry's specific information.
• Variant A presented a card collection with the different blocks, giving more importance to the visual aspect of a map to locate the country in question in an effort to be ludic about it.
• Variant B offered the map view plus a vertical tab layout that isolated the blocks to be browsed one by one.
• Variant C offered horizontal tabs with the same block principle as Variant B and the header the other database pages had.
In the end, no UI for Variant B was generated because from the design perspective, it was foreseeable that it wouldn't work well.
Variant C proved to be more visually appealing by its cleanliness and similarity to other pages in the system. The blocks in Variant A were thought to be disorganized because users could not really find an order to read them.
Other tabs
It was decided that the main tab would display the Grid Emission Factor of the country, as it proved to be the most useful information for the majority of the users.
The other tabs had then less importance according to the number of users and number of consultations in average.
• The Grid Utility Rate tab contained the compilation of all rates existing by zone, city, or region, depending on the country. Because between countries the information isn't standardized with a format or file type (some used PDFs, others, Word documents, and the worst case was screenshots of Excel files), Sales users needed to input everything manually, and this information would be later replicated to contracts or invoices, while we could work on an extraction-oriented solution.
• The Allowed Contracts tab contained the rules of which contracts could be offered in the specific country. Because of different laws or regulations, not all contract types we modelled were valid in some cases. So here the users with role Head of Region could choose which ones to apply having such regulations in mind.
• The Taxes tab allowed the Finance users to define the taxes applicable in each country, as well as the values and the date of application/validity.
• The Exchange Rates tab was introduced at the end after agreeing with the Sales and Finance teams, that a ER source needed to be standardized in the system. Via script, the ERs emitted by the European Commission were then synced, and then users from these teams could use the tab as reference instead of browsing the EC website directly.
I collaborated with the Head of Region EUR, who was in charge of overseeing the standardization of the processes for the rest of the regions where the company was operating, as well as with the Data Lead and the Operations Lead, to make sure they were informed of these structural changes so they could also follow the naming conventions and nomenclatures in their systems and outputs.
• Variant C was released with the first version (MVP) of Pulse v2. 🚀
• The feedback gotten after the launch and first usage was very positive. Users had no trouble understanding that these datasets were the backbone of any operational output they and their teams might need to generate. Everyone was happy that the data points didn't need to be updated manually by contract, invoice, or offer anymore.
5) Design system
I created the design system for Pulse from scratch following the Material Design guidelines for usability, also to make the React implementation easier, while making all components WCAG-compliant. Using Figma variables, I created Light and Dark themes.
The design system was structured in 4: Assets, Styles, Components, and Organisms (custom components).
Here's a glimpse of some assets, styles, and components.
6) Impact
Business impact
Business-wise, the clear impact was that data became absolutely reliable by introducing a source of truth for every output needed at the company: the backbone data.
Only the selected sources were taken into consideration to feed the system, closing doors to unreliable data from others.
| Adoption | From 10 users to 92 out of 95 (almost everyone in the company) |
| System performance | From aprox. 10s to max 0.3s |
Our initial success metrics were also completed. ✔
User impact
After the release, users were relieved of entering data that was repetitive by having a centralized repository of that information.
• With that, the task splitting and responsibilities were clear: who should update the backbone data points should not be the same person who is, for example, filling a contract
• Users could finally focus on their own tasks without having to manually update those data points, which implied desk research and time lost, or pasting information that might have not been updated.
7) Reflection
What I learned
• From the technical perspective, I learned having joint sessions with the Engineering Team from the very beginning, in which Product Managers, Designers, and Data Analysts also participate, is of great benefit to understand how to map an application meant to evolve and with numerous dependencies between data points. Having created a master data flow was the best approach to aid visibility for Backend, QA Engineers, and occassionally, Frontend Engineers.
• From the stakeholder alignment perspective, I learned and appreciated that constant and not excessive exchange of what's happening in the department is of vital importance in case there are changes in protocols, rules, or legal aspects that would directly impact our development. Having worked together with the Process Lead, the Data Lead, and the Head of Region (EUR) gave me a wide visibility of all these moving parts, in addition to deeply understanding use cases among regions and other departments.
What I'd improve
If given more time, I would have prioritized and worked thoroughly on:
• The project specifications feature, since this was also important for Solar Project Managers to track construction changes made to the solar panels, which directly impacted cost calculations. That would have been the last piece of the puzzle for an entire department.
• Generally speaking, maybe having increased the number of Engineering Team members to include a DevOps engineer. Because of budget limitations, we had to rely on someone external to solve our problems, and that usually implied partial pauses for the Backend Team while waiting for the deployments and changes to be completed.
8) Bonus screens
