Clarity over cleverness
If a visitor has to work out what a screen is for, the design has failed, no matter how good it looks.
Hi, I'm Reabetswe Mothle, a frontend developer, UI/UX designer and systems builder. I make digital products that are clear to use, quick to load and honest about what they do.

I started where a lot of self-taught developers start: rebuilding websites I admired, breaking them, and figuring out why they broke. What began as curiosity became a habit of taking things apart until the logic underneath made sense.
Frontend development pulled me in first, the immediacy of writing something and seeing it appear. But the more I built, the more I noticed that the hardest problems were never technical. They were questions of hierarchy, wording, and what the person on the other side of the screen was actually trying to do. That took me into UI/UX design, research and prototyping.
The third piece came from working with real businesses. A great website is only part of the answer if the enquiry it generates lands in an inbox nobody checks. So I started building the systems around the product too, automation, CRM connections, and the small operational pieces that make digital work actually work.
Today I work across all three: research and interface design, frontend development, and the systems that hold it together.
If a visitor has to work out what a screen is for, the design has failed, no matter how good it looks.
I design knowing how it will be built, and build knowing why it was designed that way.
Speed, stability and accessibility are design decisions, not an engineering afterthought.
A product that only the person who made it can update is a liability, not an asset.
Interfaces built to be fast, accessible and maintainable.
Design decisions grounded in how people actually behave.
Sites that load quickly and get found by the right people.
The operational layer that keeps a digital product running.
I ask a lot of questions at the start, because the brief is rarely the whole problem. Then I work in visible increments of wireframes before interfaces, interfaces before code, so there are no surprises at the end.
I document what I hand over. Components, tokens and decisions are written down, so the work stays maintainable long after the project closes.

Away from the screen I'm usually reading about design history, taking photographs, or pulling apart products I use to work out why they feel the way they do. I keep a running list of interfaces worth stealing ideas from, it is the closest thing I have to a hobby and a research method at the same time.