By any stretch of the imagination, the human brain is the most powerful piece of software ever built.  You may at first think that the brain is hardware, but consider for a moment how the brain reconfigures itself as you learn new things you experience everyday.  The brain is constantly creating associations and relationships between concepts you know and new concepts you don’t recognize.  Eventually as enough associations come together you start to categorize these associations into domains.  For instance, when you’re driving a car, all of the associations you’ve made while driving in the past are easily accessible for quick reactions. 

In software, these domains are called ‘abstraction layers.’  The most incredible fact about the human brain is that it doesn’t need any assistance in creating these abstraction layers.  It is this evolving nature that gives humans the ability to be dynamic, make quick decisions, and ultimately invent.

When considering People, this very artifact that makes humans such great decision makers poses a significant challenge when interacting with each other: Context.  Context is the associated information that everyone brings to a situation which makes them understand their surroundings.  This means that if two people who are trying to communicating do not have sufficiently similar context, they may not be able to communicate.  To prove the point, consider two people speaking different languages.  Usually, they revert to hand signals, facial expressions, and pointing.  In this case, the context is language, but in most cases we see communications challenges, the reason is usually about context of a specific domain.   How do we solve this problem without sending every one of our colleagues, managers, and reports to the same educational programs to acquire similar context?  The answer: Scenario Oriented Software.

Software, unlike the human brain, does not reconfigure itself to expose concepts of a specific domain.  Software is designed by a variety of different disciplines that study domains and build software around these domains.   The domain analysis results in scenarios that people in the domain undergo on a periodic basis.  These scenarios are both what makes the software relevant to the users and also what makes the users more efficient when thinking and acting in a specific domain.

Consider two separate software teams working on a similar project.  Team A uses email to communicate and track project requirements.  Team B uses email to communicate and a software project domain specific software system (ie. Visual Studio Team System) that has a centralized requirements management database.  Both teams communicate using email, but Team B uses the centralized database to store requirements and track ownership of requirements.  Team B, at any point can query the centralized database to find the person who owns a requirement and send them a mail challenging a requirement.  Team A on the other hand, would send mail to a large group of people to figure out who owns a requirement and then be able to act upon that knowledge.  Team A has a harder time communicating because their system of using only email doesn’t immediately provide context of the domain the members of Team A live in.  Team B is more effective because the software they use has in it the context that allows Team B’s members to act as they would in their domain.

Similar to the scenarios enabled by Visual Studio Team System for software teams, at Personify Design we build software for many different kinds of domains that create efficiencies.  These efficiencies can only be realized by understanding the user’s domain and challenges they face while interacting with people or other software systems.