Small but important UX update: Added item name + description to my invoice generator
Hi everyone,
I shipped a small but important update to my free invoice generator today.
A few people pointed out that invoices usually need a clear item name, not just a description. For example:
• “Kitchen Sink Repair”
• “Website Design – Phase 1”
• “Roof Inspection”
Previously the tool only had a description field, which made invoices feel less structured.
So I updated the line item system.
Now each line item supports:
• Item Name (main service/product)
• Optional description (extra details if needed)
• Photo attachments per line item
• Automatic totals and PDF export
The description field is now hidden behind a button so the UI stays clean unless you actually need more details.
I also updated the homepage hero to better explain the photo attachment feature, which many contractors and service businesses found useful.
Here are a few screenshots of the updated interface 👇
(attach the screenshots you showed me)
You can try it here:
https://invoice.gen.in
Curious to hear feedback from other builders — especially anyone building tools for freelancers or service businesses.
Small UX tweaks like this are usually underrated =(
In many SaaS tools the biggest improvements come from reducing ambiguity, not adding features. When a user sees a clear item name + description, they immediately understand what the invoice represents.
Did you notice any change in support questions or user confusion after this update?
Thanks! I completely agree — a lot of SaaS tools focus on adding more features, but sometimes the biggest improvements come from removing ambiguity in the UI.
In this case, a few early users told me they were unsure what to put in the description field, especially contractors who usually think in terms of clear service names like “Kitchen Sink Repair” or “Roof Inspection”.
Adding the Item Name + optional description made the invoice structure much clearer.
It’s still early, but the goal was exactly what you mentioned: reduce confusion and make the invoice feel more professional with minimal input.
I’m also trying to keep the interface extremely simple — that’s why the description field is hidden unless someone needs it.
Really appreciate the feedback. If you ever have thoughts on things that feel confusing or unnecessary, I’d love to hear them.
That’s a really good example of reducing cognitive load.
I’ve seen something similar in task management tools — when fields are too flexible, people hesitate because they’re unsure what “good input” looks like.
Clear structure usually beats flexibility early on.
Out of curiosity — did adding the Item Name field actually change how fast users create invoices, or mostly how clear the final invoice looks?
That’s a really interesting observation.
From what I’m seeing so far, the biggest impact is actually on clarity of the final invoice rather than raw creation speed.
When everything was just a “description” field, users tended to write long text like:
“Kitchen sink repair including pipe adjustment and leak fix.”
Now the structure naturally becomes:
Item name: Kitchen Sink Repair
Description: Pipe adjustment and leak fix
It ends up looking much more professional on the final invoice, and clients can quickly scan what was done.
Another small benefit is that it reduces hesitation when adding line items. People immediately know what the main service is vs optional details.
I’m curious to see how this evolves as more people use it — especially contractors who attach photos to each line item as proof of work.
That makes a lot of sense.
Structured input often improves the output more than the speed of creation. Once users know exactly what each field represents, they stop overthinking the input.
I’ve seen similar effects in task systems where separating title and details dramatically improves clarity later.
Are you considering adding any smart defaults or templates next?
Exactly — that’s what I’m noticing too.
Once the structure is clear, users don’t spend time thinking about how to phrase things. They just enter the service name and move on. The final invoice ends up looking much more organized as well.
Right now I’m experimenting with a few template ideas. The goal isn’t to add dozens of designs, but a small set that cover most real-world cases — something like minimal, traditional, and modern.
I’m also thinking about simple presets for common service workflows (contractors, freelancers, etc.), so the invoice structure already matches how they usually bill.
Still early though, so I’m trying to watch how people actually use the tool before adding too many features.
Fully agree!
Structure often reduces cognitive load more than adding features.
When users don’t have to decide how to phrase something, they move much faster.
Presets for common workflows sounds like a strong direction too — especially if the product learns which ones people actually reuse.
Have you noticed certain templates becoming the default for most users?
Have you seen similar patterns in task tools where structure ends up being more valuable than flexibility?
That matches what I’ve been seeing too.
Large AI-generated diffs don’t just increase review time — they also increase uncertainty.
It becomes harder to tell what is essential vs. incidental change.
Small patches force both the human and the model to stay grounded in a clear intent.
One thing that helped me was framing requests as “modify X to achieve Y” instead of “implement feature Z.”
Otherwise the model tends to redesign half the system.
Curious — do you enforce size limits socially (“please keep PRs small”) or with tooling (CI checks, PR rules, etc.)?
That’s a really good way to frame it.
I’ve noticed the same thing — when requests are phrased as “modify X to achieve Y,” the changes tend to stay much more contained. Otherwise the model sometimes tries to redesign surrounding parts of the system.
Right now I mostly enforce smaller changes socially by breaking work into smaller prompts and reviewing the output step by step. Large diffs tend to create too much uncertainty.
It’s interesting how similar that principle is to product design as well — small, focused changes are usually easier to reason about than big feature jumps.