I evangelize that we need to humanize and build real social software. Software that empowers people in their first life, is less individualistic, aims at connecting people and offers (shared) experiences in a meaningful way. We must rethink our digital design systems by introducing simple & natural models with can be used in real-time by teams. In short we abstracted our design systems too much. We must embrace soft skills into our every day design efforts. These new design models will open the door to real social software.
“Stellar UX is design research to protect our (digital) future and build a world we want to live in. How we humanize our software is the key.” – NK
In the emotion mapping design challenge we are researching if designing with emotion (not for emotions) leads to the humanization of our our software design.
In the Human Activity Pairs design experiment we work under the assumptions that if we want to humanize our software design we need to make our design methods less abstract by using a subset of our natural language. To keep things simple we only use verbs and nouns (Inspired by Well Designed, Jon Kolko) and extending his idea by adding emotional and human centricity assessment.
Introducing: Human Activity Pairs. Moving from feature to experience perception.
Our current design systems give no guidance is humanizing our software. Let’s talk user stories for a bit.
You could argue that we should split user stories into two types. UX Stories – containing no solution, just the wishes/needs and the reasoning/validation and development stories which are detailed, groomed and contain acceptance criteria for production. UX-stories can be used by UX Designers to design a potential solutions, while the UX output can be used to detail the stories in production for development. But this leads to a waterfall approach.
Solutions like rapid prototype techniques and mock-ups are actually not that fast and making variations is difficult. Another issue is that user stories only describe features within your domain and do not describe a total task completion across multiple (digital) touch points.
We need a simpler design system if we want people work together and use the collective genius of your team, organisation and ecosystem.
“If we really want to innovate and humanize our technology we should rethink how we communicate our design ambitions.” -NK
If we want to humanize our current digital design systems we need to realize that our current walled gardens (Google, Apple a.o.) forces us to think in features. We need to train ourselves in detecting bad design habits. We must choose design systems which are easy to use, and are convergent instead of divergent. (Reminder me to elaborate on this) We should always revert back to the most advanced natural design system: Natural Language. Because language turns emotions into actions.
By indexing verbs and nouns we could really simplify our ideation processes. Communicating complex concepts is still a problem we haven’t solved quite yet.
Choosing our words should become an art. For example take the word car. Do you buy a car or do you share a car? One verb puts you in an old or new economy mindset. Which means that by carefully selecting our verbs and nouns we can innovate our businesses. The words we use define us, yet we seem to throw our words around in endless meetings. Our activity pairs (verbs/nouns) are already locked up in everything we already produced, in our website, in video’s, documentation, user studies, user interviews, etc. Or simply in our day to day conversations, meetings and presentations.
If we learn how to hone in on words that really matter and use them hyper-consciously, we could invent a new way to map our ambitions.
Humanizing our word-selection process and think about the words from the user perspective will give us new ways to define value and communicate our ambitions at scale. This is where Stellar UX really shines.
By carefully managing our human activity pairs we are able to humanize our software design, while innovating our businesses at the same time. Human activity pairs make it easy to make a problem chain insightful. By asking questions like: “Is this a real human activity? What emotions are triggered with these human activity pairs?”, we can safeguard our design approaches and start humanizing technology and perhaps even safeguard our (digital) future if we define design principles to double check our human activity pairs against.
Human activity pairs is a system which can be vetted, prioritized and used as input for problem branches and experiences. Experience mapping, the follow up to this exercise, can be co-created in minutes, while creating insight for the whole team. Where user stories force us to part again to get stuff done, human activity pairs brings people together to ideate solutions.
Together with emotion mapping we can really start to humanize our software design as we move from function to emotion and from feature to experience. In the next Experience mapping exercise we will bring emotion labels and human activity pairs together as it is time to get practical.
Remember: “Most of our communication is intended to tell others how we want to be treated”.
1. How do we find our human activity pairs?
2. How do we prioritize our human activity pairs?
3. How might we use verbs and nouns + emotional and human centricity assessment to humanize our software design?
4. How do we use human activity pairs to visualise experiences and problem branches?
5. How might we use human activity pairs to create a convergent design system?
6. How might we use our human activity pairs to communicate our ambitions?
Let’s discuss these subjects in person or in a live stream on youtube. Hit me up on twitter!