Summary
Jules was an iOS home inventory app from HomeIQ. You catalogue what you own, property by property and room by room, attach the documents that prove it, and the app turns that into an insurance coverage report.
Nobody wants to inventory their house. They want to have already done it. The whole product had to survive that gap between a chore with no immediate payoff and a moment of loss that may never come.
NOTE:Draft pending Paul’s review. Written from the project artefacts and his CV; adoption and outcome numbers are the gap.
The problem
Insurance claims after a fire, flood or burglary run on documentation. The insurer wants to know what you had, what it was worth, and some evidence you actually owned it. Almost nobody has that. People reconstruct it from memory under stress, months after the purchase receipts went in the bin, and settle for less than they were covered for.
The obvious fix, a list of your belongings, is also the reason these products fail. Data entry is the entire cost and it lands upfront, while the benefit is hypothetical and might never arrive.
My role
Product and UX designer in a startup, which meant the job was wider than the screens. I helped define product strategy and UX direction, worked across product planning and the business discussions behind it, and kept user needs and market demands pointed at the same thing.
On the craft side: interactive prototypes, wireframes and the design documentation the build ran on, plus usability research and testing to refine features and improve engagement.
Structure first
The data model was the design problem. An item belongs to a room, which belongs to a property, and a person may hold several properties with very different contents: a main residence, a rental, a holiday home. Get that hierarchy wrong and every later screen inherits the mistake.
The flows and screen inventory were mapped in full before the visual design existed, so the structure could be argued about while it was still cheap to change.
Design response
Made capture the shortest path in the app
Cataloguing is the cost the user pays. Adding an item, its brand, model, serial number and price, had to be the fastest thing the product does or the library never gets populated.
Grouped the library by property, not by category
People think in places, not taxonomies. The item library leads with the property and its item count, so a user with three properties is never browsing one undifferentiated list.
Let documents live on the item
Receipts, warranties and photos are the evidence an insurer asks for. Attaching them to the item is what turns a list into a claim you can actually file.
Turned the catalogue into a coverage report
Linking items to homeowners, vehicle and other policies gave the inventory a use before any loss, which is the only thing that justifies the data entry.
What this project shows
Designing in a startup, not just for one. Product strategy, planning and business conversations were part of the role, not something handed down to me as requirements.
Consumer motivation as a design constraint. The enterprise work on this site deals with users who have to use the tool. Jules had users who could stop at any moment, which puts the burden of proof on the product every single session.