medium bookmark / Raindrop.io |
Looking for Part 1? ← Can technology be better for humanity?
The following tenets explain the of concepts and foundation of a theoretical operating system called Humanic. A system centered around human needs first and foremost.
The goal of Humanic is to get out of the way in order to become a digital companion to human nature by addressing basic human wants and needs. It’s less important that something is or is not an application. What is important is addressing user intent as quickly and efficiently as possible. In order to do so the focus is on creating a lightweight structure that can work together harmoniously.
What is important is addressing user intent as quickly and efficiently as possible.
The structure of Humanic is comprised of three pillars: Experience, Functionality, and Media. Each pillar is defined by a series of elements.
The experience is what people will be directly interacting with most. They may not understand the way something works behind the scenes, but they will know what they are looking for, and how they expect to get there.
This is the most fundamental part of why Humanic exists. Without intent, there isn’t a purpose for a Humanic Operating System.
An set of expectations established by users that define the methods by which users aim to pursue intent.
What the user sees, interacts with, and assumes is doing the work in the pursuit of their intent.
This is how the sausage gets made. This gives people the ability to turn intent into useful information.
The interactive layer that helps design the feeling of a mechanism.
An instrument that is used in the pursuit of function.
The functional methods by which intent is actually being pursued.
This is the information people want, they way it should be, from the sources they choose.
Any information or media provided by a source.
Any meta or contextual information that needs to go along with content.
A contributor, creator, or curator of content.
Besides helping create definition, the three pillars of structure allow for elemental growth paths. This means that elements within the structure of Humanic can evolve as needed without refactoring the entire operating system.
While structure helps define a backbone for Humanic, the pillars and elements should exist as a cohesive experience. No single pillar’s abstraction is useful without the the harmonious entanglement of its counterparts. This is why harmony as a concept must be understood and respected when envisioning, or extending the Humanic experience. Without harmonious abstraction, Humanic is an amalgamation of ideas.
Where the intention of this structure is to define elements, and abstract them at scale, harmony is intended to consolidate these elements in order to seamlessly addresses user intent. The easiest way to understand harmony within Humanic is to conceptually build the system from the ground up. Let’s start at our most crucial element — intent. Without having an intent, there is no rationale for a user to interact with a system to begin with.
Example: Intent being translated into elements being created by, and used by an app like AirBnB
Think about pulling your phone out of your pocket. Chances are it’s not just to put it back in your pocket, you want to create a note, ask a question, or check the time. All of these are intentions.
Once an intent is defined a Function becomes defined. Any defined Function requires an Engine in order to fulfill a users request for that intent. This is what powers any given Intent, and is made interactive by the use of Mechanisms. Mechanisms are interactive tools for users to understand and communicate with the operating system. Think of Mechanisms as translation points between the user request and a system function. They could be radio buttons, combo boxes, date/time pickers, or any method in which a user interacts with the system. Mechanisms are made more evident to users through the use of Behaviors. Behaviors are allusions or metaphors that lead the user to understand how a mechanisms will affect a function.
If the previous paragraph was too much of a dive into this logic, here’s a more practical analogy. Imagine you’re in a car, and you want to go forward. This is communicated to the literal engine through a throttle mechanism. The throttle is interacted with through a behavior, and since you’re in a car, this is likely you pressing your foot into a pedal. If you were on a motorcycle your intent, engine, and mechanism would be the same, but your behavior is what differs. You use your hand and twist on the a handle in order to control the throttle (a mechanism).
Let’s stick with this car analogy for a minute. In the paragraph above, we described an intent being transformed into a function. If we were to analyze the parts described we had one user defined concept, and three system defined concepts. The user defined the intent, and the system (or company) defined the engine, mechanisms, and behaviors. If we were going to go further down this path into the experience spectrum, we would see that the interface, and constitution were also not user defined. If those were to be analogized, the interface would be the way this pedal, in this particular company’s make and model of this car, looks. The way your foot rests on the pedal is setup in the way the company intended, and is the color and material it is because that is what the company intended. And every one of this company’s cars comes ‘standard’ with this sort of pedal. It’s not defined by you, the user. Nothing you interact with in the car is. The way you roll down the windows, the way you turn it on, lock the doors, open the gas cap, or even the colors available to you aren’t defined by the user. They are defined by the company.
It’s not defined by you, the user…They are defined by the company.
Now let’s take this analogy a little further. For the sake of adding some additional tangibles to this situation, we’ll say the car we were using was a Fiat500. Now having driven a Fiat500 recently, I can tell you there were at least two strange behaviors, mechanisms, and interfaces that I dealt with in the car itself. One: In order to lock the doors, you push in the door handle. Two: The controls for both windows are buttons in the center console. These were all selected by Fiat. I did not select the mechanism for the door handle, or the behavior or interface for the window controls. Now in almost every car I’ve ever been in, these functions (locking the door, rolling up/down the windows are done via some interaction with the door). The function here is not the issue for me, the user. The issue for me is the other three parts. I didn’t find it intuitive that the door handle being pushed in was the way to lock it. I would have preferred a different mechanism, let’s say the same one found in a Honda Civic where a rocker button engages or disengages the lock along with an indicator that shows a lock/unlock icon or color. Say I also wanted to move the window control mechanism to the door, but using a button found in a Nissan Altima. I as a user, have an idea of how I want things to look (interface) and how I want to interact with them (behaviors and mechanisms).
I don’t really care what Fiat, Honda, or Nissan want me to do. Nor do I think any of them single handedly can build the perfect car for me, and everyone simultaneously. But that’s the constraint they deal with working in the real world, with physical objects. But those who build digital things have the capability to stop building an application for the lowest common denominator while allowing ourselves to contribute in our strongest suit. Maybe our Map engine is the best one out there. Maybe it’s our scroll bar interface. Maybe it’s our swipe to like behavior. The point is — we don’t all need to rebuild everything, every time. We can build, iterate, and contribute to the best human experience possible, by focusing on the original user intent, and the requirements for that intent.
As designers, developers, and entrepreneurs we need to think about this holistically. We need to remember why we as humans are carrying these devices around, rather than focusing on how we’re going to make money with it.
In an era where people have access to such a wide array of information, so much is done by operating systems, and application creators in order to churn a profit in their direction. So much developer time, designer time, and more importantly user time could be saved simply by better examining human nature.
Is it almost noon? Chances are we’re about to look for lunch. But rather than putting answers within arms reach, everyone is required to enter a slog of unpredictable behaviors in order to find an amalgamation of results from a few different sources. For the sake of proving a point let’s just walk through the idea of getting lunch.
Time Spent: 1:48
So much time can be saved simply by thinking about this system not just based on user intent, but by human nature and the experiences we all go through everyday. We might all be unique snowflakes in our own wonderful way, but if there are fifty applications completing the same task, chances are the human experience throughout is common, it’s the minutia that’s different.
AI-driven updates, curated by humans and hand-edited for the Prototypr community
