Making Complex Products Work for More People
When you work on an operating-system product like ZimaOS, one question is hard to avoid: do the capabilities we find valuable actually matter to everyday users?
Take NAS devices. Your data lives on your own drives; you can expand capacity, install apps, build a media library, and even run a home server. For people who enjoy tinkering, those are compelling reasons to buy. But explain the same thing to someone who simply wants to keep the photos on their phone, and they may ask, “How is this different from the cloud drive I already use?”
That is not an easy question to answer. We can talk about data ownership, privacy, local access speeds, and long-term costs. But they can open their cloud drive and see their photos right now. They do not have to think about when a drive might fail or whether their home network can be reached from outside. An advantage that makes perfect sense to a product team may still not be enough reason for a user to switch tools.
In my earlier piece, Notes on Building a Markdown Editor, I wrote about a similar trade-off: Markdown being friendly to AI does not mean it fits the way an organization collaborates. Local products are no different. Owning your data and server sounds appealing, but users still need to understand how much extra work those capabilities ask of them.
This essay uses NAS devices to explore a few questions: where does the barrier of a complex product really come from? Which parts of that complexity should the product absorb, and which parts do users genuinely need to understand? And when we carry these lessons into AI tools, what cannot simply be copied over?
1. Are users buying storage—or a maintenance job?
Imagine that you want to keep your family’s photos together on one device. Before buying, the need seems simple: photos from each phone should arrive automatically, be easy to find when needed, and survive a phone upgrade. Once you start, though, you may first need to choose drives and a storage setup, understand RAID, create accounts and shared folders, and then sort out phone backup, permissions, and remote access. Before you have stored a single photo, you have already taken an introductory course.
Every one of those settings exists for a reason. An engineering team cannot casually remove one, because households, networks, and storage requirements do vary. But the user only wanted to save photos. They did not set out to learn how to administer a server.
Finishing setup is only the beginning
It is easy to concentrate the experience problem of a complex product on first use: can installation take fewer steps, can technical language be made plainer, can we add an onboarding guide? All of that is worthwhile. But even when users complete setup smoothly, the work that follows does not disappear by itself.
The device needs updates. Drives fail. A backup can stop because it runs out of space. Changing a router can mean reconfiguring remote access. If users return to the admin interface six months later, will they remember how they set it up? If they replace the device, can their files, accounts, permissions, and apps move with them? These issues are rarely prominent on a product page, yet they continue to shape the experience.
Keeping data on your own drives does not necessarily make leaving the product easy, either. You may be able to copy the files, but album organization, sharing relationships, application data, and automation settings may not travel intact. For someone who has spent years working around a system, rebuilding those things is a cost too. A product that emphasizes data autonomy should at least make clear what happens when a user eventually stops using it.
That is why I prefer to understand complexity in terms of the work users must carry. More features do not automatically make a product harder to use. A capable product with sound defaults and a recovery path after failure may demand far less effort than a tool users must assemble for themselves. Setup is only one part of the purchase; ongoing maintenance, migration, and dealing with failure belong in the calculation too.
This is also one reason cloud services are easy to choose. Part of what users pay for in a subscription is the ability to hand some maintenance work to the provider. That does not mean a cloud drive can never lose data, nor that customer support guarantees recovery; it depends on the service. In everyday use, however, users usually do not need to replace drives or maintain the runtime environment themselves. You cannot compare that difference by the price per unit of storage alone.
Being afraid to act can be harder than not knowing how
If the task were merely learning a few operations, it would not be so difficult. Someone may happily spend hours learning a camera, an espresso machine, or a game because they care about the result and roughly understand the cost of failure. But when a device holds years of family photos, even an interface with only a few options may feel too risky to touch.
Suppose the system asks the user to reinitialize a drive. Someone familiar with storage can tell which drive it affects, whether it contains data, and whether a backup has already completed. An ordinary user may see only one line: “This action cannot be undone.” Adding a more detailed help document will not immediately make them feel safe. What they really need answered is: will this affect my photos, what should I check first, and who can help if something goes wrong?
This is why I find “users simply do not want to learn” too convenient an explanation. Learning becomes much easier when a product lets people try something, preview its consequences, and recover from mistakes. Some actions truly cannot be reversed, though. A product should not disguise them as ordinary clicks just to lower anxiety. Make recovery robust where recovery is possible; explain consequences and help users perform the necessary checks where it is not. That is more useful than adding the same generic “please proceed with caution” warning everywhere.
2. First decide why more people should use it
At this point, it may seem that the next step is to improve the NAS onboarding experience. But there is an earlier question: does it actually need to become a mass-market product?
If a group of users clearly needs local storage, extensibility, and finer-grained control—and is willing to pay for those capabilities—serving that group well is already a valid product direction. Professional tools are not obliged to appeal to everyone. For people who treat configuration and expansion as part of the enjoyment, the things we think should be removed may be exactly why they chose the product.
The real question is which new users the product intends to serve, what unmet needs they have, and how much additional work the team must take on to serve them. Otherwise, “going mainstream” easily becomes a growth target with no specific audience behind it, and ultimately gets reduced to a prettier interface, fewer buttons, and more lifestyle-oriented marketing.
Why would someone whose cloud drive is good enough switch?
If someone’s photos and documents fit in their current cloud drive, sharing is easy, and the price feels acceptable, continuing to use it is a perfectly reasonable choice. We should not assume that a user is making a shortsighted decision simply because a NAS offers more control. Capabilities they do not need have no immediate value to them.
“It may be cheaper in the long run” also needs to be calculated carefully. Beyond the device and drives, there is electricity, backups, replacement hardware, and the time spent on maintenance. The answer can differ by capacity and length of use. Likewise, keeping files at home is one way to manage data, but poorly configured remote access and permissions do not become secure simply because they are local.
Rather than repeatedly explaining the theoretical advantages of a NAS, I think we should look at where existing tools genuinely leave users dissatisfied. A creator who regularly shoots large volumes of video may need fast local access to footage and access from multiple devices. A team may want documents to remain in an environment it manages without returning to a collaboration model of emailing files back and forth. Such needs at least explain why the current solution falls short and what extra cost users are willing to bear.
“I want to own a server,” by contrast, is often the language of a product enthusiast. For everyone else, a server is simply one way to achieve an end. If the end is not clear, reducing installation from ten steps to five is unlikely to create a reason to buy.
Could AI create new demand?
Seen from this angle, AI does leave local products with a few opportunities worth testing. If someone keeps a large body of material locally and wants AI to organize, search, and use it over time, then where files live, who can access them, and what may be handed to external services become practical questions. A local device may have a more important role to play.
But this does not lead directly to “everyone needs an AI-powered NAS.” Storing files does not mean a device has sufficient inference capacity, and running a model does not mean it can complete a user’s work. Users may also solve the same problem with a computer, a hosted service, or another device. Adding AI to a product page does not automatically make the original reason to buy more convincing.
For product teams, these changes need to be tested in specific situations: do users really encounter this problem often, how difficult are existing tools to use, and can the added value of a local solution cover the cost of deployment and maintenance? Design can lower the barrier to trying something; it cannot manufacture a need that does not exist. Nor do we have to reduce every opportunity to waiting for the market to change. A team can still choose a more suitable audience and delivery model, then make one narrow need work end to end first.
3. Even the simplest use should be worth it
Assume we have found people with a real need. Only then does the question of how to help them use the product come next.
A common approach to complex products is to divide features into basic and advanced layers. New users see a few entry points first and reveal more options as needed. That is easy to implement in an interface, but one question is often missed: if a user stays in the basic layer, is the product already good enough?
Someone who buys a NAS and uses it only to back up photos has not necessarily made the product a failure. If backups are reliable, finding and recovering photos is easy, and that one job is worth the money and time they spend, the product has done its work. There is no reason to require them to install containers or build a media library just to prove the device was worth buying.
Start with one complete job
If family photos are the entry point, the journey from connecting a phone and transferring photos to viewing, sharing, and recovering them after a phone change should be one complete experience. Users should not need to understand the system’s entire directory structure first, nor should they be asked to learn a permissions model halfway through a backup.
This does not mean the system can have no folders or permissions. The product needs to offer a default suited to this situation so users can begin, while explaining the boundaries when they matter. For example: which photos can family members see when they join, does deleting a photo from a phone affect the copy on the device, and what remains accessible after someone leaves the family group? These are concrete consequences users care about, and they are easier to understand than role inheritance or storage paths.
Automation has conditions of its own, too. A phone may lack authorization, background tasks may be limited, or the device may not have enough space; any of these can leave a transfer unfinished. A product cannot make only the happy path simple and leave users to diagnose every exception. A genuinely complete basic feature includes the experience of failure as well.
There is a parallel with the choices we have made for Folio. If we want ordinary users to manage and share documents in a local environment, this workflow must work first. The number of underlying system capabilities may determine future room to expand, but it cannot become knowledge users must master before completing their first collaboration.
A phone does not need a shrunken admin console
For a device that runs at home over the long term, a phone is well suited to handling everyday issues. But if we merely shrink the PC administration console and fill the home screen with CPU, memory, temperature, and network-throughput readings, users still have to decide what those numbers mean.
Someone who has just taken a batch of photos wants to know: have they all transferred, which ones have not, why did the transfer stop, and what should I do now? If the system can say, “128 photos are waiting to transfer; connect to Wi-Fi,” it does not need to make the user hunt through a task list for an error code. The raw logs should remain available for further diagnosis, but they do not need to be everyone’s first screen.
The same is true of notifications. Successfully completed tasks can remain in the history. A brief interruption that can retry automatically may not need to interrupt the user immediately. But if a backup has been failing for an extended period, or there is not enough remaining space for the next one, the product needs to make that clear. The point of a notification is to help someone decide whether to act, not to prove that the system is always working.
The thing that requires the most restraint here is a reassuring-looking “everything is fine.” A device being online does not mean photos are backed up. A file being synchronized does not mean it can definitely be recovered after accidental deletion. If several distinct states are collapsed into one green checkmark, the interface may feel simpler, but the user may make the wrong decision as a result. We do not need to show every technical detail on the home screen, but we cannot omit information that changes what users should do.
4. An AI task being complete does not mean its result is usable
The lessons above apply to AI tools too: sensible defaults, a clear task scope, states that are easy to inspect, and a path for handling errors. But bringing NAS design over wholesale introduces new problems.
For a file backup, we can check whether a task ran, whether the files finished transferring, and further confirm the result with checksums and recovery tests. Hidden failures are still possible, but at least we can inspect the work against relatively clear rules. When AI produces an analytical report, task completion, a complete body, and correct formatting do not prove that its judgments are right.
Users face two different kinds of uncertainty: “I do not know whether the system followed my settings,” and “the system did work, but I do not know whether I should trust what it produced.” A progress bar, completion message, and smoother output cannot solve the second kind on their own.
Leave an entry point for checking the result
Suppose a user asks AI to turn several documents into a project summary. The product can show which files it read, which it failed to read, and link the key claims in the summary back to specific sources. When users find a conclusion that feels off, they can at least return to the original material instead of searching through the entire knowledge base again.
But citations alone do not make something correct. A source may be outdated, a model may misunderstand its context, or a link may point to text that does not support the conclusion. Sources are therefore only the start of verification. The product also needs to make it easy to inspect the original, revise a conclusion, and distinguish content that remains unconfirmed from content ready to use.
Likewise, placing a “95% confidence” label on a result, or showing a long and apparently detailed chain of thought, may not help users judge it. How was that number produced? Does it correspond to a real error rate? Can the explanation on display actually be checked? Rather than making the interface seem more certain, I would rather it tell me what this task used, what it lacked, and which points still need my confirmation.
This does not mean placing a warning beside every generated paragraph. Low-risk wording changes and factual judgments that will inform a decision should not demand the same intensity of review. A product needs to direct people’s attention to places where errors are more likely or more costly; otherwise, too many alerts will simply be ignored together.
When AI starts changing files, recovery matters even more
If AI only offers a suggestion, users can still choose not to use it. But when it begins reorganizing directories in bulk, rewriting documents, or changing permissions, the result directly affects existing work. At that point, beyond checking content, the product needs to limit what AI can do and record what it actually did.
For example, it can show which files will be affected before a rewrite, provide a diff afterward, handle deletion, overwriting, and external sharing as distinct operations, and retain versions for reversible changes. That gives users a chance to accept only part of the result instead of choosing between trusting everything and using none of it.
In the piece on Markdown editors, I also noted that an agent’s actions may span multiple files and multiple sessions. The editor’s current Undo/Redo is not enough on its own. These capabilities need the file system, permission system, and versioning service to work together. In an AI context, the product still has to absorb complexity; it simply takes on one more job: helping users determine whether an apparently completed task was actually done correctly.
5. In the end, it still comes down to who handles the trouble
When I look at NAS devices and AI tools together, I do not think what they lack is a friendlier visual language. The hardest parts are usually invisible to users: whether the default is reliable, whether exceptions can be found, whether there is a recovery path after failure, and whether the product has clearly explained what it cannot solve.
These issues also change the commercial trade-offs. If we want users to stop managing remote connections, updates, and troubleshooting themselves, the team needs to provide the corresponding system capabilities and support. They all carry ongoing costs. We cannot treat them as work that disappears after hardware is sold. In turn, users need to know before buying which capabilities are included in the device, which depend on continuing services, and what will be affected if those services stop.
For people who genuinely want to maintain things themselves, retaining configuration entry points, open data formats, and migration paths remains important. Giving users good defaults and allowing them to take over are not in conflict. What we need to reduce is unnecessary work—not take away their right to decide how to use their own device.
So if we return to the person at the beginning who simply wants to save photos, I would rather the product already knows how to keep those photos safe, show which ones are not yet safe, and help when something goes wrong than continue explaining how many kinds of services the device can also run. If they need more capability one day, it is still there. If they only ever use it to store photos, it should still feel like money well spent.