Engineering for Evolution

The criteria for engineering a good user experience spans across diverse incentives.

Ease of use is the most well known one, but I find it to be subjective. A cognitive device that helps me when in the development cycle is a flavor of iterating with the question of “how do I make this more intuitive?”. This follows from the realization that even for measurement along qualitative dimensions, we generally find comparing two entities (and ranking them higher/lower) easier than to come up with an absolute measure of that quality and resuming with a global sort. Working on concrete iterations also allows me explicitly think out loud in terms of what worked and what did not and then abstract later on for future wisdom.

I usually see transparency being deprioritized under the guise of ease of use. A deliberately high opacity of abstractions so that the user only deals with what they need is slightly demeaning for me as a super user. In my experience, Emacs does transparency really well : I can have highly abstract M-x bindings along with the choice to jump around and into the source and be able to modify it for myself. Consequently : the idea of Adaptive User Interfaces emerges : think of having a completely transparent set of exposed utilities that are masked/flavoured based on the level of the user’s inquisitiveness about the tool itself. Again, drawing out of concretes, you have to tinker around enough to finally/accidentally (keystroke seizure?) unlock a feature (buffer narrows for instance) and feel the need to use it. One could even think of it as engineering/planning for the users’ evolution.

This is a reason to like emacs: the “self documenting” aspect really starts compounding over continued use.