Hachi

Household grocery shopping sounds simple — until several people are involved. Someone notices that something is finished. Someone else says they’ll buy it. Another person goes shopping and forgets something. A message gets buried. Someone buys an item that was already purchased.

The problem isn’t necessarily the shopping itself. It is the coordination around the shopping.

I became interested in that small gap between knowing what a household needs and actually coordinating that information between people. That became the starting point for Hachi.

Existing ways of coordinating household groceries often rely on tools that weren’t specifically designed for the problem:

The underlying problem I wanted to address was: How might a household maintain one shared understanding of what needs to be bought without turning grocery management into another chore?

That question shaped the product. Rather than designing a complicated household-management platform, I wanted Hachi to focus on one thing and make that thing feel effortless.

I began by thinking through the situations surrounding grocery shopping: Who notices that something is missing? Who adds it? Who is going shopping? What happens when someone buys it? How does everyone else know? What happens when plans change?

These questions helped me move away from designing screens and toward designing the state of the household. The product wasn’t simply a checklist. It needed to communicate a constantly changing shared state.

That became an important principle throughout the design: Hachi should make the current state obvious.

I mapped the basic journey before thinking about visual styling. The goal was to reduce the number of decisions someone has to make when adding or checking an item.

I explored the core interactions around: Adding → Tracking → Updating → Completing.

The resulting experience needed to accommodate both the person adding groceries and the people who would later see, update or complete them. This helped establish the foundation for the MVP. Instead of filling the product with features, I focused on making the central loop understandable.

I moved from the product structure into flows and wireframes. At this stage, I deliberately stripped away visual decoration. The questions were more basic:

The wireframes became a way of testing the logic of Hachi before investing heavily in its visual language.

Once the core experience was established, I began developing Hachi’s visual identity and interface. I wanted the product to feel approachable without becoming childish, and distinctive without allowing visual personality to interfere with usability.

The interface became a balance between four core principles:

The visual system grew directly from the product’s functional requirements.

One of the more interesting design problems was that Hachi isn’t purely an individual productivity tool. Its information belongs to a group. That changes how the interface needs to communicate.

An item isn’t simply: "I added this." It becomes: "This is something our household currently needs."

That distinction influenced how I thought about hierarchy, status and interaction. The interface needs to help people understand not just what they did, but what the household currently knows. This became one of the central ideas behind the product.

Although Hachi is a product-design project, I didn’t want the visual language to feel disconnected from my broader design practice. I approached the product as both a functional interface and a visual system, exploring graphic composition, typography, visual hierarchy, illustration, interaction, motion, and art direction.

Lanre supported the visual direction of the project. My role was to connect the visual work back to the product experience — asking: Does it communicate the product? Does it belong to the same visual language? Where can the product afford to be expressive, and where should it remain functional and quiet?

This is where multidisciplinary practice becomes useful: design and engineering aren’t separate projects, but parts of the same product.

The project became particularly valuable to me when I moved beyond the design file. I built the frontend and turned the product into a functioning web/mobile MVP.

That changed the way I evaluated my own design. In Figma, an interaction can look finished. In a working product, everything has consequences: spacing becomes real, responsive behaviour becomes real, states have to exist, and interactions have to actually work.

My process became cyclical: Think → Structure → Design → Build → Test → Adjust. Implementation exposed problems that weren’t always visible in design, turning Hachi from a concept into a working MVP.

Hachi is currently available as a working web/mobile experience, with the product being prepared for launch. The MVP represents the first practical version of the idea rather than the final version of Hachi.

The next phase is about learning from real use, identifying where the experience creates genuine value and deciding which parts of the concept deserve to become more developed.

For now, Hachi represents something important: an idea I didn’t leave inside a notebook or Figma file. I took it through the messy middle: researched it, designed it, built it, and turned it into something that exists.