I learned my first lessons about users from readers.
For years, I was a web novel reader. Then I started writing my own novels and published them in WebNovel, MegaNovel, NovelCult. That journey taught me something I didn't expect…
1. Creating something isn't the same as understanding how people experience it!
Whether you're writing a story or building software, you can spend hours working on something and still miss what the person on the other side needs.
Every author knows too much, one of the first things I noticed after becoming a writer was how difficult it can be to judge your own work.
When I write a chapter, I already know what is going to happen. I know why a character made a particular decision, what a certain line is supposed to mean, where the story is going. The reader knows none of that. They only see what I've put on the page. This creates a strange problem.
As the creator, you can look at something and think: "This is clear."
But it may be obvious because you already know the answer. I've found the same principle applies surprisingly well to software. A developer knows how their application works, but a user doesn't.
The developer knows where a feature is supposed to be. The user just knows whether they can find it. The developer knows what an error message means. The user just knows that something went wrong.
2. Feedback changes the product
Writing multiple web novels also taught me to become less defensive about feedback. That's not always easy. When you've spent hours creating something, criticism can feel personal.
But feedback isn't always saying:
"This is bad."
Sometimes it's saying:
"I experienced this novel differently from what you intended."
That distinction matters. If many readers misunderstand the same part of a story, I can't simply tell them that they misunderstood. I have to ask why, maybe the explanation wasn't clear enough, the pacing was too fast, or an important detail was missing.
The same thinking is useful when building software. If users repeatedly struggle with a feature, telling them how the feature is supposed to work doesn't solve the problem.
The better question is:
What did we build that caused this experience?
3. Editing taught me another lesson
My involvement with the editorial team at NovelCult gave me an even better perspective on this.
When you're editing and giving on someone else's work, you're not trying to replace the author's voice.
You're trying to identify where the author's intention isn't reaching the reader clearly. Sometimes the problem is structure, it's pacing, or it's a missing explanation. This reminds me of code reviews.
A good review isn't about proving that the person who wrote the code was wrong. It's about finding places where the implementation can become clearer, safer, easier to maintain, or better aligned with what the software is supposed to do.
The goal is to improve the thing being built.
Web novels are interesting because they're often serialized. You don't necessarily write the whole experience once, release it, and forget about it. You write, and readers react. You observe, learn, and then you continue. That creates a feedback loop.
Software development works in a similar way. You build something, people use it, discover and report problems. Then the developers will change it, and release another version.
The important part is creating a process that allows you to learn from the first attempt.
4. Readers taught me to think about the person on the other side
When I was only a reader, I never thought much about how much work went into a chapter.
I simply wanted the story to be enjoyable. That's actually a useful perspective for a creator.
People don't experience your effort. They experience the result. A developer might spend three days implementing a feature. The user doesn't experience those three days.
They experience whether the feature solves their problem. An author might spend five hours rewriting a chapter. The reader doesn't experience those five hours. They only experience the chapter.
5. Documentation has the same problem
This is also why I've become more interested in clear documentation. When you build something, you become familiar with it. After using the same codebase for months, concepts that once seemed complicated become obvious to you.
A new developer joining the project doesn't have that context. If the documentation assumes knowledge that the reader doesn't have, the documentation has failed, even if everything inside it is technically correct.
Writing stories taught me this from another direction. The reader shouldn't have to know what was inside the author's head. The important information needs to make it onto the page. Good technical documentation has the same responsibility.
The biggest lesson in my journey from reader to writer to editor wasn't something I planned as a lesson in software development. But it changed the way I think about building things.
I've learned to ask:
- What does the person using this see?
- What information am I assuming they already know?
- Where could they misunderstand my intention?
- What does feedback tell me about the experience?
- What is the smallest change that could make the experience better?
These questions work for stories. They work for documentation, and they work well for software.
I’m still interested in both sides of the process: creating things and seeing how other people experience them. That's one reason I continue exploring the web-fiction ecosystem as both a reader and a creator. NovelCult is one of the platforms I've been exploring for independent web fiction and authors.
For me, the interesting question is always the same:
Can we make the thing we're building easier and better for the person on the other side?
