Hypothesiz

What if users don’t know? What if they accidentally delete something? They may not know the format. They may not read instructions. They need to be told where to go next…

Thus, we dumb down the experience and make it foolproof. Instead, if we trust that people are smart, we could have:

• Visual cues and affordances instead of excessive text-based help.
• Learnable interfaces — a path for a novice to become an expert.
• Complex experiences that are not complicated.
• Recovery mechanisms instead of confirmations.

People may be new to the product or domain, but they are not stupid.

Tasks in enterprise products often require permissions, approvals, and/or decision-making. A seemingly simple task like naming convention can often hit roadblocks, causing delays and friction in workflows.

So, it is better to place actions or inputs with dependencies at the end of the workflow. This allows smoother progress and minimizes the impact of potential bottlenecks. Provide help and recommendations if possible. The goal is to minimize friction towards completing an action.

Incremental fixes do end up complicating the product incrementally. 
We are forever stuck on loops of fixing issues, adding features in a hurry and then executing a long term cleanup projects to simplify it.

Not all fixes or features complicate it though. It is the odd ones which don’t belong to the structure the system already has. When we make exceptions in the structure for this, we are breaking the structure. Then we add more such elements, breaking the system bit by bit. 

So, the question is, how do we scale without deviating from the structure. Or better even is to build a structure which takes into account all the oddities and doesn’t break.

Understand volume of work to while designing for efficiency.

Is it a ticketing system where user has to create or address atleast 20 per hour?

Is it an inventory management system with millions of SKUs and thousands of order pick/pack operations per hour?

In a monitoring system that raises alerts only when critical issues occur (maybe once or twice a year)?

Along with the volume also understand the urgency, frequency and pace of the task. Can it be done at a leisurely pace or is it in a firefighting mode?

We designers advocate user-centered approach. But, are all systems catering to people.

1. Systems serving other systems: integrations with subsystems, monitoring and backup systems ensuring smooth operation and maintenance of these interconnected components.
2. Self-Serving Systems: record-keeping and management systems that are essential for its own operational efficiency and governance.
3. System serving Business Operations: Operations and inventory management systems. They streamline various business processes and workflows.

So, along with usability, delight and other user centered concepts consider operational efficiencies, scalability, workflow optimization, compliances and compatibilty with the existing infrastructure.

Sci-fi and fashion shows push the boundaries of imagination and creativity alike.

Sci-fi transport viewers to futuristic worlds, expanding the notion of what is possible. Fashion shows influence direction of fashion in the upcoming seasons. Both are speculative and not immediately consumable.

Viewer response for both is different though. Sci-fi creates aspiration, new abilities, powers, etc. Whereas in fashion identity, self expression, comfort, fit, choice, etc. come to mind. Whoever has asked “Is the fancy glass interface even usable?” but a fashion show always evokes “Is this even wearable?”

Generously use clichés. Maybe overuse them. Make a button look like a button, work like a button and place it right where people expect them to be. It is not just about design patterns and elements. Go ahead and steal the mental model of the people using the product. Mimic their language and behaviours in the product. This makes the interaction flow familiar and predictable. 

But, this doesn’t mean stringing together known elements. Solve a real problem that a user is facing. And execute it in a way that feels effortless and intuitive. 

Real design is what happens after and before we get all the elements together.

Server outages happen often at the front desk. The trained staff knows to transition from digital to manual.

But, the key is in timing. When should they switch. Switch too soon, and effort is wasted if the system comes back. Delay too long, and customers get frustrated waiting.

The push to go manual is low as data must be re-entered later. So, even after the switch, should they keep checking intermittently if the system is working again, or just ditch it entirely.