ZippoGreen - Online Lighter Store
Revamped a retailer's online presence for simplified product order
Role
Duration
12 weeks
Tools
Figma, HTML/CSS, React, JavaScript, MySQL
Team
Just me 🧘
GitHub
Background
ZippoGreen relies heavily on social media for sales, leading to a manual and inefficient ordering process.
ZippoGreen is a lighter retailer in Hanoi that is primarily based online through social media. While this provided visibility, the ordering process was labor-intensive: customers had to message the store directly, and staff spent significant time replying, confirming orders, and tracking inventory.
The problem
How might we give customers a more streamlined way to shop and make orders?
My solution
A dynamic, operational e-commerce website for ZippoGreen.
Research & Ideation
Interviews with the store manager revealed 2 main struggles:
📚 Customers struggled to find past products buried under old posts.
🕝 Staff spent too much time on processing and managing orders
The nature of social media sales created multilayered obstacles for both customers and staff, leading to reduced customer retention and productivity.
ZippoGreen needed to move from social media to a proper sales channel. We had two paths:
Join an existing e-commerce platform
✔️ Fast to implement
✔️ Familiar to users
✖️ Limits future growth
Develop a dedicated website for the business
✔️ High scalability
✔️ Stronger display of brand identity
✖️ Higher upfront cost
Which was the most suitable pathway?
The store manager's initial instinct was to use Shopee, but there were clear limitations.
Shopee is a popular e-commerce platform where most customers already had accounts. But its limitations became clear when I asked about their future plans: they wanted to offer repair services and build a local brand identity.
We'd be locked into their templates, their checkout flow, their fees. There were little flexibility for their business model.
I argued that paying upfront for a custom site would cost less than migrating later.
⚖️ The trade-off
If I couldn't build it well enough, we'd waste time and have to fall back to using Facebook or Shopee.
The technical challenge
As the sole designer and developer, I knew this meant designing only what I could actually implement.
I was learning React simultaneously while building this, so every design decision faced a reality check: Can I actually build this? Will it ship on time? Does it solve the core problem?
The manager wanted to ship the website in 2 months. These constraints forced clarity: I couldn't hide behind unrealistic concepts.
Design decisions shaped by constraints
Technical limitations coupled with time constraints helped me define the MVP scope clearly.
Modal-based product details instead of dedicated pages
My initial wireframes had separate pages for each product. While coding, I realized this meant managing routing, loading states, and back-button behavior, easily an extra week of work.
Switching to modals kept users in their browsing context and cut implementation time in half. The "limitation" actually reduced friction.
No filter or search bars
The original wireframe had a sidebar filter and search bar, but coding them would have delayed launch by 2 weeks.
Instead, I simplified the navigation during development by adding category tabs and price sorting, which solved the searchability problem with 20% of the effort.
Auto-calculating cart totals instead of manual entry
This feature was non-negotiable for preventing order errors. The technical implementation (managing cart state, updating totals on quantity changes) was complex, but it eliminated the back-and-forth that happened when staff miscalculated customer orders on Facebook.
The struggle with solving two problems at once
The store manager wanted a solution for both customers and staff, but this came with a risk
The website needed to work for two completely different users: customers browsing for products, and staff managing inventory.
Early on, the store manager insisted we include an admin panel for v1
`They were worried that without it, staff would still need to manually update product availability, recreating the same communication bottleneck we were trying to solve.
I pushed back initially. Building an admin system meant:
But the manager had a point I hadn't considered:
The compromise I made
I built a fairly simple admin panel—just enough for staff to view orders, and add, remove, or update items.
I accepted that this would add timeline risk, but the alternative was launching a half-solution that could damage trust with their existing customer base.
Outcome
The website didn't launch—and that taught me more than shipping would have.
The project took longer than anticipated. As I was learning while building, implementation stretched beyond the store's timeline. They needed something operational immediately, so they hired a professional developer to rebuild it.
Reflection
This felt like a failure at the time. In hindsight, it was a highly valuable lesson.
ZippoGreen was the first web-based project that I developed from scratch, and it taught me the challenges in transferring design into code to ensure consistency and practicality. Therefore, my design focus for this project was technical feasibility rather than aesthetics, which allowed me to learn a lot about how information architecture and user interactions are developed.
This experience has allowed me to better understand engineers' workflow and technical capacities, which I hope will help me collaborate with them more effectively in cross-functional teams.
What I’d do differently
🗓️ Timeline estimation when you're also the builder matters more than I thought.
I underestimated how long authentication and database setup would take by about 3 weeks. If I'd been honest about my skill gaps earlier, we could have either adjusted scope or brought in help sooner.
This experience completely changed how I work with engineers now: I would ask about implementation complexity early, not after designs are finalized.
🔬 I'd test the product categories with actual customers before launch.
I assumed categories that made sense to the store would work for shoppers, but never validated that. We might have discovered customers think in terms of price range or occasion or if a different approach is needed to improve searchability.
🫸 I'd push back harder on including the admin panel in v1.
If I were in this situation again, I'd scope v1 to just customer-facing features and push the admin panel to v2. Shipping something imperfect that customers could use would have been more valuable than attempting a complete solution I couldn't deliver on time.