Designing the portal where solar panel, heat pump and air conditioning installers pick up the customers iChoosr sends them, and take each one from first visit to an approved delivery.
Installers needed one portal to take iChoosr’s leads all the way to an approved invoice.
One portal that guides installers through every step, from new lead to approved invoice.
What slows partners down today?
I started with the installers themselves, to understand their needs and the problems and bottlenecks they hit in the old system.
Then I talked to the colleagues who work with installers every day. They know where partners get stuck, which questions keep coming back and where deliveries go wrong.
Together, the interviews gave a clear picture of the journey every installer goes through with a customer, from the first lead to an approved delivery.
What does everyone really need, in every country?
I turned the interviews into an empathy map to capture what installers need and what frustrates them. Then I used a strategy canvas and a Kano model to decide what the portal had to do really well, and what could wait.
I ran in-person and online workshops with business reps to define which information and documents are needed at each step, and what installers and iChoosr expect from each other. Everything had to work for all 5 countries we operate in.
Requirements differed from country to country, so we sorted every piece of information and every document into three groups. This kept the core flow the same everywhere, while each country still got what it needs.
What could it look like?
We sketched the first wireframe prototype together during the workshops, so business reps could react to real screens instead of descriptions. We went mobile first, which kept every screen lean and quick to use.
I mapped the flow of each step, like requesting delivery approval: what the installer does, what iChoosr reviews, and how changes, withdrawn requests and declined deliveries are handled.
I refined the prototype and tested it with installers from each country, the people who will use the portal every day. The tests allowed us to validate our concept and confirm that we on the right path. We used the learnings to re-iterate our assumptions and flows. Each session used realistic scenarios for every section, from assessment to approval, plus one end-to-end task, and we tracked task success, time, errors and hesitation.
How does it come together?
Once we knew how the portal would connect with HubSpot and the other systems, I mapped the service as a blueprint: what installers do at each step, the screens they touch, and the people and systems working behind the scenes. Then I zoomed in on each interaction, like filtering or searching the customer list, and mapped the action, the decision behind it and how the portal reacts, including what installers see when nothing matches.
The portal needed components our design system didn’t have yet, so I designed and added them. I gave special attention to the data table, search and filters, since installers rely on them constantly to manage long customer lists. Each one covers its key states, like default and error, so it behaves the same everywhere it’s used.
With the components in place, I designed the screens for every step of the journey, from picking up a lead to submitting a delivery. I aligned the designs with the product manager along the way.
Installers told us exporting new customers was confusing: what counts as new, and what will be exported? Now one button exports only the new customers of the day, and the page shows when they last exported.
Does it work, and is it ready to ship?
Before handing over, I ran another user testing campaign with installers from each country to verify the final designs.
With the designs verified, I handed them over to the developers. We launched with a handful of pilot installers, then gradually rolled the portal out to all partners in every country, fixing what we learned along the way.
What did real use teach us?
Once the portal was live and installers were using it every day, we realised something the tests hadn’t shown. We had kept the submit button disabled until every required field was filled, and some installers never noticed it become active. They left without submitting, so their deliveries never reached us. We changed it: the button is now always enabled, and pressing it shows clear errors on any required field that is still missing. It’s a reminder that discovery doesn’t stop at launch. We keep learning from how the portal is really used, and keep improving it.
