With the design principles established and roles reorganised, the work shifted to translating what we had learned into the product itself. Every implementation decision was run through the same filter: does this serve transparency, accessibility, explaining the output, or keeping users in control?
Our visual design assumption going in was clean, simple and colour-guided, informed by benchmarking competitors. It worked: 85% liked the design, several called it professional, and the colour-guided experience was something users responded to without being prompted, which gave us the confidence to carry it into the prototype rather than rethink it, as you will see.
The feedback from round one split clearly: visual design held up, messaging didn't. Over half of users didn't know what DPE was before starting. Without understanding the core concept, they couldn't trust anything the tool told them. We added a plain-language explanation with the full A to G scale to the landing page, a direct transparency fix. The "not sure? check your…" tooltips came from the same place: if users don't know where to find the information we're asking for, we're not being transparent nor following the design principle of accessibility.
Accessibility drove the smaller but equally important changes. Two users had to scroll to the top manually between every step. 58% didn't know what was happening during calculation and assumed it had broken. Both got fixed: automatic scroll to top, a loading state, and a restructured output that brings the most useful information forward.
Explaining the output was the biggest structural change. Multiple users interpreted "potential cost" and "annual cost" differently, and none of them accurately. The results page was reorganised into five named sections with ROI framing throughout, what the work costs, how long to pay back, what you save per year.
Keeping users in control came down to two specific findings. One user pointed out that only being able to select one heating type was inaccurate for most homes. Another said there was no way to skip questions they genuinely couldn't answer, and suggested showing a live estimate for users who don't know their bill. Both changes were implemented afterwards.
Round two was conducted this week across fourteen users, again one-on-one and observed, on the fully independent version of the prototype. The prototype was originally conceived through Lovable as mentioned before, but then all the code was exported and made independent. The prototype now lives on GitHub where it can be easily implemented with the backend created by Nicodème. This switch allowed us to have greater creative freedom and thus flexibility to implement user feedback. The results of the second round of user feedback have not been implemented yet due to it being conducted so recently.
The second round had to be postponed due to the technical difficulty of linking up the platforms and the unstable nature of the program hosting our websites. This became apparent during second round user testing where certain features that worked for some users did not work at all for others. This was clear with the live bill estimate feature that was subsequently changed, also following internal feedback from the team.
Terminology was the most consistent issue, flagged by 64% of users, words like "draughts", "glazing", and "pellets" created confusion that directly contradicts our accessibility principle; this will be changed. One user flagged that "could save you thousands per year" is an overestimation when their bill isn't in the thousands, which is a transparency failure.
On explaining the output, one user thought the main number was what they had to spend rather than save, and another found the savings figure changing between sections without explanation. On keeping users in control, one user found the "not sure" button visually present on the heating step but non-functional, and there was no option for users without a laundry machine. For all these issues a solution will be found that will be ready for user testing round 3.
Several users specifically praised the tooltips, the landing page user statements, and the depth of the recommendations section, a decent rise in satisfaction compared to user testing in round one.
Looking back, the two rounds of user feedback gave us valuable insights that could subsequently be implemented in the new prototype, but it did not only show us a list of bugs that needed solving, it also revealed deeper insights regarding our design principles and messaging. The Base44 MVP proved the concept worked but assumed too much of the user: that they knew what DPE was, that they could find the information we were asking for, that they would understand what the output meant. The prototype stopped making those assumptions.
Each design principle became a concrete checklist against which feedback was measured, which meant decisions had a rationale beyond gut feeling. That shift, from building what seemed right to building what users showed us was needed, is what the iteration process actually produced.
The first version of the product was built on Base44 as an MVP to validate the concept and run the first round of user testing. You can still access it below.
Following the first round of user feedback, the entire product was rebuilt as an independent prototype with greater flexibility and a direct connection to the Supabase backend. This is the current version of ÉcoWatt.
The next round needs to go further than testing usability. Messaging has been the central challenge from the start, the biggest failure in round one, and the explicit goal we set out to improve in round two. It got better: 92% of users understood what the product was, which wasn't the case before. But it's not solved.
The independent version introduced new language problems that weren't in the Base44 MVP, and beyond translation, the content itself still misleads in places. The next round needs to measure not just whether users can navigate the tool, but whether they genuinely understand what it is telling them at every step, and trust it enough to act on it.
We already drew the DoctoLib parallel in our business model section: free for users, monetised through the professionals on the other side. We said we'd "move charging contractors to the farther future." This is what that looks like in practice.
Right now, when a user gets their results (a heat pump makes sense, double glazing would pay back in 8 years), the next step is completely off-platform. They google an installer, get three quotes they can't compare, and the decision drags on for months. We've seen this in interviews. The tool does its job, then loses the user at the exact moment they're most ready to take action.
The fix is straightforward: each recommendation surfaces a short list of RGE-certified contractors (Liste des entreprises RGE), "Reconnu Garant de l'Environnement", the French certification required to unlock MaPrimeRénov' subsidies, filtered by postcode. One tap from the result to the person who installs it.
For contractors, the pitch is simple. RGE installers have no shortage of demand right now. MaPrimeRénov' has pushed renovation onto a lot of people's radar, but most leads they get are cold. Someone who's already used ÉcoWatt, seen their payback period, and clicked "find an installer" is not a cold lead. That's the value of the referral, and what makes business-side revenue coherent.
No contractor agreements needed. ADEME and Faire.fr already publish a public RGE directory by postcode. We surface it in-context, attribution included, consistent with how we've handled data sourcing throughout.
The DoctoLib model proper: verified contractor profiles, lead notifications, and a listing fee or per-referral structure. We'd test it with a few willing firms before building anything more.
100 completions (not visits, not signups, full flow to results) is the target. The number itself is less important than what it unlocks: enough data to see where users drop off, which property profiles cluster together, and a sample size that makes user testing round 3 actually meaningful rather than anecdotal.
We've been doing this on LinkedIn and more extensively on our personal website. To increase visibility, we posted it on the governmental platform for our project, reaching 614 views total. The Forward College Instagram post got 2 reposts and 61 likes with zero spend. The next step is a conversion-focused post: a short clip of the tool, a direct link, a concrete ask. Target: 15–20 completions.
We tried Paris rental groups and got almost nothing back. Those groups exist for people posting searches. The better target is owner groups: co-propriété forums, landlord networks, MaPrimeRénov' discussion groups. In a group of 20k members, 0.5% engagement is 100 clicks. Target: 30–40 completions.
Both rounds of user testing drew from this population and it worked well. A direct ask through Forward College (students, families, alumni) with a "use it and tell us what's broken" framing gets us completions and feedback at the same time. Target: 20–30 completions.
The highest-intent users we could find. Forums where owners already ask "is a heat pump worth it for a class E apartment": our exact product proposition. A genuine answer to the question, with the tool linked, not a promotional post. Target: 20–30 completions.
Channels 1–3 can run in parallel now, no budget needed. Channel 4 needs more care to not come across as spam, but it's the most valuable traffic of the four. Realistically: 100 completions in 4–6 weeks after launch, with around 30 of those being return visits or referrals.
The three things we'll track: completion rate (how many people who start actually reach results), where in the flow they drop off, and once contractor listings exist, whether anyone clicks through. Those three numbers tell us if the product is working. Traffic alone doesn't.