This is somewhat similar to a previous question, but not the same.

Our system is evolving and learning based on data and is designed to suggest some course of action for end users.

Initially, we will need more and more user intervention to validate the suggestions, so that users need to do a detailed scrutiny of system suggestions

After maturity, the suggestions system will come up with will be near perfect and the users can accept the suggestions without detailed scrutiny.

I am confused to design for the early stages where the detailed scrutiny screens take more importance vs the later flow, where the detailed scrutiny screens, albeit essential, will take a secondary stage.

One thought is to design in a phased manner where we update the screens once the system matures, but then there will be a learning curve for the same set users, twice.

Any thoughts?

Thanks in advance.


3 Answers 3


In this particular instance, I'd suggest transparency.

You are asking users to use a tool in its early days, where they will get less benefit initially, but where you expect them to see an increasing return on their efforts as the tool matures.

If you are not clear and open about that from the outset, the poor effort-to-benefit ratio is likely to put users off and you'll never see the tool reach that maturity.

However, if you can clearly explain the trade-off to your users, and give some kind of indication of how close the tool is to optimal, you might be able to bypass that and even turn it into a way to generate interest (which, of course, comes with it's own risks, too).

It's hard to give much solid advice about how to do all of that without more information, but for me to stay engaged with such a tool, I would need to see:

  • Some (option) information about why my input NOW would help the tool improve
  • Proof that I wasn't the only contributing user
  • An indication (based on real usage data) of how long it will be before the system is mature enough to be reliably useful
  • A confidence metric for each suggestion delivered, with information about why it is low or high
  • A mechanism by which I can feed back on a suggestion if it was incorrect, and the impact of that incorrectness (an incorrect suggestion with no impact is less bad than an incorrect suggestion which had a high impact).
  • Some kind of average success metric, with signs of it improving over time.

Design for the version users have today

The product will evolve in ways you can't yet understand. You can slowly train users toward the future you envision, but the current workflows are paramount to their immediate experience. Users will care very little about ultimate value if you don't give them something valuable right now. For example ...

Facebook feature release timeline

  • 1
    This makes a lot of sense to me. Barring the fact that you don't really know what the final solution will look like, you generally want to make the actions you need the user to take the easiest. Right now, that's providing feedback. Later on, it will be something else. Apr 10, 2017 at 17:15
  • +1. This is probably the best approach. Learning on the way may have some reworking disadvantages but as an approach this is the best solution. Apr 11, 2017 at 5:44

This is a hard question.

Going one way leaves you with non-optimal interface that would be easier for Users to learn, and get used to. There will be more to rework in the future, and the Users you will already have on board will probably reject these changes, as they will be used to using the non-optimal one. This may even lead to these Users leaving your system as you improve it.

Going the other way, will allow building the optimal interface with time, but the learning curve for it will be harder for the Users, which may affect conversion to registrations, so Users will not get on board at all. The question is, though, if this direction, considered as optimal now, is something that Users would want after all? Maybe it will need pivoting anyway.

Personally, and just in general (because for specific cases it may be different) I would build the non-optimal interface slightly optimised towards the more powerful (and complex) one. This way you would achieve three things:

  • as the interface will be easier to learn, registrations should be quite high,
  • you would validate some hypotheses for the interface considered as perfect now,
  • you would be closer to the perfect one at the end, so the adoption for Users will be easier, so you would not loose as many Users as you would in case of a total revolution.

However, reworking will still be necessary due to some "user experience debt" if i may call it like this.

I would also invite some Users to co-creation of the system (5-10 early adopters in constant communication loop).

Does this answer your question?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.