Reflections on UX in Indie Development: Designing for Non-Engineers

Introduction

I am a self-proclaimed non-engineer.

Yet, at some point, I realized that my perspective when building products had become "slightly engineer-oriented." I was designing UIs based on the standard of "myself getting carried away"—someone who could open a terminal, understand file paths, and read configuration files reasonably well. (This was pure arrogance.)

It’s a funny story, really. Even though I hadn't been in the field for long, I had somehow ended up on that side of things. Honestly, I was getting way too full of myself.

Trying to achieve "everything is included when you open the app"

When I built StoryForge, a novel writing app that uses local LLMs, I initially designed it with the assumption of a procedure like: "launch llama-server, configure the port, specify the model..." (Well, it was originally just for myself, after all.)

Because I could navigate that process without any trouble, it seemed obvious to me.

But thinking about it, if I were to sell this app, most of the people who would want to use it are "people who want to write novels," not "people who can touch a terminal." It’s natural that they wouldn’t know how to launch a server via CLI. I suspect they don’t even know the term "local LLM."

So, I changed my approach. I decided to hide the launching of llama-server, port settings, and CUDA version selection entirely within the app. I would limit what the user has to do to just three steps:

1. Launch the app
2. Select a model
3. Start writing

"Everything is included when you open the app." If I can achieve this, even non-engineers won't get stuck.

I still need to pull the models from somewhere, but I checked the licensing and used direct links so users wouldn't literally get stuck.

Ever since I set that goal, I feel like the resolution of my design improved significantly.

From there, it was a flurry of polishing, such as implementing context-aware onboarding.

StoryForge, in particular, is built on the philosophy of "everything is included, but not everything is explained at once."
While I do have some onboarding, I wait until the user clicks, for example, on a "Consult with AI" feature before explaining how to use it.

I realized that onboarding isn't just about teaching everything all at once.

Create the flow, and show the explanation only when the user wants to use it. That is my belief regarding what constitutes thoughtful UX.

The obvious fact that the words we use matter

There is the term "LLM." I use it normally, and I understand the meaning instantly. But would this be understood by non-engineers?

That’s why, within the app, I honestly replaced it with the word "AI."

Depending on the intended user, the words they understand, the operations they expect, and the level of complexity they can tolerate all change. I thought I understood this in my head, but when actually designing, I usually forget it.

It’s like clearing away the thought of "this is basic, isn't it?!"

What I learned by placing a virtual user

In my case, I started specifically imagining "someone who would want to buy this on BOOTH."

For example, someone who writes fan fiction but isn't tech-savvy. Someone who wants AI to continue their novel but finds ChatGPT difficult because they feel their settings keep slipping away. Someone who isn't good with English UIs and is looking for something that works properly in Japanese.

When I kept these people in mind, the words I used in the UI, the button placements, and the courtesy of the error messages all changed.

For example, when exporting takes time, displaying just "Converting..." vs. "We are having the AI format your text. Depending on your environment, this may take a few seconds to a few minutes" results in a completely different sense of security. The former is from my perspective (for someone who understands the process), and the latter is from the user's perspective.

I even think it would be fine to write something like, "Thank you for your hard work on your writing. It will take a little time to output, so please take a break."

Realizing I had become an engineer-minded person

Looking back, there are a few realizations.

I used to list all settings without collapsing them into "Advanced Settings." I displayed console messages as-is when errors occurred. I casually used words like "parameters," "model name," and "base URL" in guidance text.

These were all things I did for the reason that "I would understand it."

Perhaps I was forgetting that I came from a non-engineering background. As you get used to something, you forget where the version of you that wasn't used to it used to get stuck.
I say non-engineer, but what’s difficult here is that I can handle PC operations at an above-average level. Even among non-engineers, there are levels of computer literacy. For example, someone who can do general PC operations but doesn't know what a command prompt is, or someone who doesn't know the term LLM but can ask a chatbot for advice.

Of course, I also understand that making things simple isn't always necessarily a good thing.
Having an experience where "I don't know why, but it worked!" means that if something goes wrong, you are stuck. That’s a problem in its own right.

Just being conscious of who you are building for changes everything

I don’t think being conscious of "who you are building for" is that difficult.

However, in individual development, you tend to become your own best user, and it’s easy to get pulled into that perspective. Especially when the technical side becomes fun, you end up spending more time thinking about implementation than about the user.

I am still exploring this myself. But I have developed a habit of pausing and asking, "Is this UI/UX understandable to a general user?" Just doing that, I think, makes a bit of a difference.

---

This article summarizes my thoughts during the development of StoryForge (a local novel writing support app using local LLMs).

---