User Driven UI

We use software to solve a problem. When someone chooses a new software product. Instead of solving their problem, we give them another. To learn the UI (User Interface). If the software is at a certain level of complexity, new users will only learn parts of it or not use it at all.

Zone of Proximal Development (ZPD)

People learn best when in the Zone of Proximal Development (ZPD). It is the space between what a student can do without help and what they can't do, even with help. Below is a list of math tasks. Ranked from easy to hard.

If a teacher took on a new student, they would first assess them. To find the hardest task the student could do without help. Imagine it was Student can combine 2 groups of marbles... The teacher would then create lessons based on the task above it. Student can solve a 2 digit addition problem... Because it is in the ZPD. The area one above what the student can do without help. Teaching something above the ZPD will result in the student becoming intimidated and overwhelmed. Teaching below means teaching content already learnt.

The Problem

When a software product is first released, it is an MVP (Minimal Viable Product). It has the least amount of features required to deliver value. The less features, the simpler the UI, the easier to learn. Over time, features get added. The software becomes more powerful. More complex. Harder to learn. Consider three different users.

One begins using the software when first released. With a minimal UI, it's easy to learn and quick to master. When the creators release a new feature, it is little effort to learn that too. As the user has a solid foundation to build on top of & it is a small amount to learn. Considering creators release new features one at a time or in small groups, rather than several at once. This user is a power user. They get a feeling of joy and confidence when using the software. They get max value from the product. They are always in the ZPD.

Another user begins using the software three years after release. The UI presented to them is the MVP and three years worth of added features. The complexity intimidates and overwhelms them. They don't have time to learn everything. Resulting in learning the least amount to solve their immediate problem. When the creators release a new feature, the overwhelming feeling grows. They don't understand all existing features let alone this new one. They get limited value from the software. Sticking to the parts they know. They are always above the ZPD.

The third user adopts the software five years after release. They take one look at the UI and abandon it. Looking for a simpler solution.

Existing Solutions

Solutions to teaching UIs include onboarding walkthrough. A tour of the core features. Pop-ups highlighting parts of the UI with snippets of text and / or video. Its flaw is not providing a chance for the user to practice what they learnt before moving to the next feature. After explaining a feature, the user needs to use that knowledge to consolidate it.

Progressive disclosure. Only revealing parts of a UI when required. For example, the modal that appears when you click save as. Revealing parts of a UI based on what the user is doing is effective at moving the user closer to the ZPD. Workspaces do a similar thing. The user selects what task they are doing. The UI then changes to only show a subset of features related to that task. An extreme approach to a reduced UI is creating a product that is a simpler version of a more complex one. For example, Photoshop and Photoshop Elements.

Simple Tools

I always liked the idea of a simple tool. A tool that does one thing and does it well. We could make software like this. Refine the MVP instead of adding to it. This would solve our problem. Keeping the user in the ZPD. It would always be easy to learn, master and get max value. The problem is, after some time, you start saying, "If only it could do this ..." or "I wish it could integrate with that ...". The value of simplicity decays over time. Once you are confident with a tool, you want more from it. To increase the max value.

The inverse is true for complex tools. They are hard to learn. It takes time to master and get max value. But, once you do, you have a valued skill. The value of complexity improves over time. Often, users don't reach this point. The way these tools are taught always places the user above the ZPD. A place no one likes to be. So they learn the smallest amount and stop. Limiting the value. Can you name a piece of software that you know inside out?

Another thing to consider with simple tools is the user, not the UX (User Experience). Would people be better with 10 simple tools or 1 complex one? The problem is not software complexity. It is the software not adapting to the user's ability. Not keeping them in the ZPD.

New Solution

With the capabilities of natural language processors, we can create a new approach to teaching UIs. User-driven UI. Instead of pushing features onto the user, the user pulls them in when needed. The software always presents a new user with the MVP. Regardless of how many features have been added since the initial release. For example, lets say you downloaded a new painting app. The initial UI would be a blank canvas with a few essential features. The square, circle and triangle tool.

There would also be a text input. If the user couldn't do something with the UI, they would enter what they are attempting to do. Using a natural language processor, like ChatGPT. The software would return a list of features that could help. Each has a button to add them to the UI. Going back to our painting app. Imagine you wanted to add color to a shape. With the current UI, you can't. Enter "Color a shape" into the text input, the paint bucket tool will become available to add to the UI.

The UI would grow in complexity, in pace with the user's knowledge. Along with keeping the user in the ZPD, it also provides:

• ▪ a non-intrusive way of providing educational content about features. When the user wants them. The results from the text input could contain links to documentation, videos, examples, ...
• ▪ an efficient and automated way to inform the user a feature they want isn't available yet,
• ▪ a non-intrusive way to collect data about what problems users are trying to solve and
• ▪ a way to know which users want to be notified about certain feature releases. Allowing you to be more accurate when using new feature pop-ups. Making the software less one-size-fits-all.

Like all approaches, it has flaws. One being, by hiding functionality, users may be unaware of features. Leading to them not reaching max value.

For user to reach max value in complex software, they need to be in the ZPD. This requires multiple approaches. In the past, teaching has been considered an after-thought to making the product. Underestimating the value of teaching. Resulting in power user making their own educational content. This is a mistake. You could have the cure for cancer. If people don't know how to use it, it might as well not exist. Creating a tool for someone to use and ensuring they know how to use it are equally important.

References

Where to Next?

Notes
    
  │
  └── Design
        
  │
  ├── Juice
        
YOU ARE HERE
        
  │
  └── User Driven UI