When you are beyond the prototyping stage and start to put together an early version of something you intend to use yourself extensively and probably also give to a small number of people to try out, what are the measures you take and practices you follow to make that a great experience? For instance, what do you do to make sure data isn‘t reset or lost between updates or can be migrated easily?

I usually pick 3 use cases that are close to real problems, add some helpers to make them easier to try, implement export/import, with export/import I implement templeate loading with a few clicks, later persistence and an easy way to "continue where you left off". Regarding migrations, in the early stage I assume and communicate that I will break backwards compatibility periodically, at some point I decide that the serialization format should be stable and start taking backward compatibility seriously.

These questions, IMO, are different stages of a product. I’ve personally had and seen (even very recently) examples of not focusing on the root issues in the product. Knowing your customer, what behaviors they have, and what behaviors you want to bring to them is instrumental. You should prototype to get learnings, not data. Data will skew your insights because it’s easy to misinterpret it or have a bias looking at the data you want to see and not the data you should be seeing. Forget the data — focus on UX.

@Steve Not sure if I explained that well enough: by „data“ I mean the data users put in to use the software. Think of a note taking app where you put in your notes. You won‘t get any value out of it, if you don‘t trust that you‘ll be able to get your data back out or it‘ll be corrupted by the next update and you have to start over. So I‘m mostly concerned about the user experience. It seems you interpreted this differently?

What are you optimizing for? It sounds like scaling, uptime, and trust. If I were to create a novel approach to taking notes I would not advertise to my initial test users anything suggesting the information they enter will be saved; in fact I would explicitly tell them that anything they enter could be lost at any point during these initial prototypes as we are optimizing for learning user behaviors.

@Steve Oh, I see where you‘re coming from. I‘m not looking for product / startup advice. It‘s not an MVP, and I’m not trying to attract investors. What I‘m doing is still much more research than business. I was more looking for technical advice and best practices on how to migrate data across changing schemas, or alternative techniques to be able to change significant parts of a system while simultaneously having a small number of people actually using — not just testing — it.

@Stefan gotcha! I’m happy to chat about how to attract investors, it’s something I’ve done before: both attracting and helping others.

@Stefan my response wasn't right then 🙂 related to migration, I implemented a serialization library that has versioning, so I can register functions that will migrate fron version N to N+1, when I encounter an old version while deserializing I run the migration functions until the last one, tl;dr: migration on read, keep all versions info, this means I can be carrying versions forever if I'm conservative, I will report the experience (hopefully) in a few years 😛

@Mariano Guerra Your thoughts on import/export and serialization were on point. I‘m also looking for a broad set of approaches for the more abstract challenge of minimizing friction for users. Migrating data was just a more specific example for one area where I know it‘s going to be a challenge. I‘m using a statically typed language, but I‘d still be happy to look at how other languages approach this. And now I‘m even more intrigued to find out how that distinction is connected to the problem?

in statically typed languages to avoid the versioning being a pain I guess you could use avro/protocol buffers which support versioning and migration, in dynamically typed languages it's easier to "patch it as you go"

Thanks, @Mariano Guerra, lots of great ideas here! Using URLs to short-circuit onboarding is something I hadn’t thought about and would be extremely simple to do. And I can already see so many uses for this, not just to get people to a specific part quickly, but also to trigger certain debug/support actions, because I can totally schedule a call with a user, send them a link, and ask them, “Hey, can you click that link while we’re on the call?” Which could also trigger some sort of data model migration, ha! Re migrations: I’m probably using JSON and dedicated model structs just for import/export. Then I can add properties whenever I want and handle larger structural changes in the actual data structures one level higher, with a lightweight migration transformation that only has to work in one direction. A lot of the other things you mention are also good for onboarding in general. In hindsight kind of obvious that what I was asking for is somewhat related to onboarding.

the other way around a notebook can be downloaded, so if someone gets stuck they can share the notebook via a file with me and I can check it out

@Mariano Guerra It just occurred to me that it was totally unclear that I’m thinking about a packaged app, not a web service. Which is probably why that URL idea caught me in a very different sense than you probably intended or expected, as I understand you provide a web-based service/app. :-) I’ll check out the book. They had quite a copy writer for that landing page…

Specifically wrt data schemas, @Stefan have you seen Cambria from Ink & Switch? Its early research but could be interesting reading https://inkandswitch.github.io/cambria/