@wcoolsJust like it’s easiest to come up with a product idea by solving your own problem, the best way of figuring out how it should work is by dogfooding, i.e. using your own product.
For some of the problems we want to fix with Thymer it’s very clear how the app should work and solve them. These are things we’re currently trying to do with a plain text editor but don’t work well. In a way, the workarounds we’re using now because the app doesn’t exist yet are a sort of pre-MVP prototype, giving us plenty of ideas to work with.
For some elements of the app, we know what problem it should solve, but we don’t know yet if a solution we came up with on paper (literally, as a paper sketch is usually the first step) works really well. That’s where it’s helpful to build small prototypes to bring the idea to to life.
It doesn’t need to be complete yet, but just enough so we can actually start using these parts of the product and see if this matches the experience we had in mind. Over time a product will change a lot anyway, but making sure the core works really well by using it ourselves helps getting an MVP out with enough initial fans to get more feedback where to improve in the first place.
It’s not always possible to dogfood every aspect of the app yourself. Our existing product for example is used by companies 100x our size. In this case it’s still important to test the app, using a sort of test persona, i.e. trying to think like the end-user and about what their workflow might be. Another useful tool is populating the app with test data. If we’re a team of two and only have two items in a list, but our target audience persona works at a company of 100, what happens if we add a 100 items? Usually this goes a long way towards fixing the most obvious problems.
Thinking about these UX/UI issues from the beginning can feel like premature optimization, and of course launching a new product is always a bet in a way. But simply sitting back and waiting for feedback to roll in is not without risks. If an MVP doesn’t feel polished enough in the right places, users might drop off before you get to hear about these issues. Another problem is that fundamental design decisions regarding the very core of the app are very costly to fix. To take the example of our existing product again, we originally shipped with a permission system which was too complicated when teams had dozens or hundreds of users, and those are our best customers! As you can imagine, permissions touched pretty much every part of the app, so we could have saved a lot of time getting this right from the beginning and not having to change it later on.
You can usually tell when products or services aren’t really used by those who designed it. They’re often confusing or come with very obvious mistakes, which everyone would run into it, if only it was used enough. The same is true for individual features within an app. That’s why we try to avoid having too many core features we can’t dogfood ourselves.
