Designing Situational Applications

Posted: 5/19/2009 4:52:44 PM
You know you need some software or a web application to help you solve a problem, but how do you get started? This series of posts will walk you through the process from idea to building the situational application.
If you are new to Situational Applications, you may want to check out Jonathan Sapir's soon to be released book, Power in the Cloud. I had the privilege of reading the final draft and it's a good read if you want to help push your organization in the direction of better information management.

In this series of posts, I'll take an informal approach to designing Situational Applications. The goal is to help you understand your information problem better and break it down into manageable pieces that you can then construct with your development environment or Application Platform. Qrimp is an example of such a situational application platform.

Most information management systems center around three things: People, Processes, and Things. Before you get started building your application, writing down everything you can think of related to these three topics will help you capture everything that your application will need to do. That doesn't mean you are going to build out all of the functionality that you describe, but the more you make concrete before you get started, the better you'll be able to plan your attack. Think of it like you think of a business plan for your company. It is a plan for building a system that helps you manage some part of that company.

Situational applications connect People to Things and help them manage the Processes that keep everything up to date and move information through the system.


The People are the users of your system. They log in, they search for information (things) and they perform actions in the system (Processes). They can see Things, or parts of things, based on who they are and which roles they are assigned to. When thinking of the people involved, sometimes it is easier to think of them as individuals and sometimes as their position within the organization.

Once you know who will be using your system, write down each role on one line of a piece of paper or in a chart. One line for each will help you draw lines between them and the Things and Processes later. These lines and relationsips will show you how the different parts of your application work together.

Some examples of people who may use your situation application are: Hiring Manager, Customer Service Representative, Tech Support Agent, Sales Agent, CEO, Account Manager, or Librarian. Each of these people will work with different things through different Processes, i.e. functions they perform.


The Things in your situational application correspond to the data you want to store. If you are building a Customer Relationship Management (CRM) system for example, some Things will be: Customers, Accounts, Interactions and Support Requests. Again, on a piece of paper, scribble down all the things you can think of related to this particular problem you are trying to solve. Put them in a chart, with the name of the thing at the top, then below it, list different properties of the thing like this:
Customer Name
Phone Number
Customer Contact
First Name
Last Name
Email Address
Phone Number
In future posts, I'll talk about how to determine relationships between information. In the scenario above, you might imagine that a particular customer has more than one contact. You talk to a contact in Accounts Payable when you want to get paid and you talk to the decision maker about selling them additional products or services.

After you write down all the Things, draw lines from the People to the Things they can see or can't see if that will be easier. This will help you define security settings for your Qrimp app. If there isn't enough room for lines, use a color coded system of circles or check boxes to indicate which People can see which Things. You can even get more detailed and talk about who can Create, Read, Update, and Delete each item. On the lines you've drawn, add a C, R, U, or D.

The goal here is less about being neat and formal and more about getting the information out of your head as soon as the ideas pop into it. Try to write down more than you think you may implement. In subsequent posts, I'll show you how to take these thoughts and make them more organized, and order them based on priorities and difficulty to implement. You want to build a system that can do as much as possible quickly, then add to it later. What we want to do is identify manageable chunks of the application that make sense to be built together in different iterations. You can read more about Iterative Development at Wikipedia.


In general, Processes correspond to verbs and Things correspond to nouns. Above, we mentioned talking to our customers. Talking is an example of a Process. You will want to make note of any Processes that come to mind. A process is something that happens. It's a description of how information moves through your system.

Let's stick with the CRM example. In a CRM, a common process is the Sales Cycle. Between the time your potential customer is a lead and the money is in the bank, many different people in your organization may talk to the person to get more and more information that will help you solidify the customer relationship and determine the best products (another example of Things) for that customer.

Employees and applicants are Things in many Human Resources applications. Candidates apply for jobs, their resumes (Thing) are reviewed (Process), they are interviewed (Process) on the phone (Thing) and in person, and eventually they may be hired (Process). At this point, they become employees. Employees (People) have benefits (Things) and complete (Process) performance evaluations (also Things).

Remeber, Processes correspond to verbs (what people do) and Things correspond to nouns (the object of the verb). You can also think of the People as the subject of the sentence, "Bob (People) searches (Process) for the Customer Account (Thing). Then he adds a note that he talked to their Accounts Payable Contact." As an exercise, find the People, Processes, and Things in the last sentence of that quote. I'll include the answers at the bottom of this post.

Getting Started

I had a conversation today with a potential client who asked if we could help him build a system. To get started designing the system, I recommended sit down and start typing out everything he could think about the application and I recommend the same thing to readers. Don't worry about grammar and spelling, just type it out as fast as you can think of it. The goal is to get infromation out of your head so it can benefit you later and other People soon.

When you are finished, circle all references to People (users of your application), Things (nouns) and Processes (verbs). It may help to use different Ink colors or shapes to differentiate each category of item in your application.

In my next posts in this series, I'll create a sample brainstorm and highlight the People, Processes, and Things. Then, we'll map those items to concepts in a Situational Application and build the sample system.

I hope this will help walk you into your application. I know in the beginning, it's difficult to get everything out of your head. It won't all come out at once and as you build and use the system, it's almost inevitable that you'll remember things you forgot and have to make some changes, but that's why web platforms are so great for solving problems quickly -- changes can be made easily as you learn more about the system.

What were the People, Processes and Things in that last sentence? "Then he adds a note that he talked to their Accounts Payable Contact." He was Bob (People). Adds and talked are Processes. Note and Accounts Payable Contact are both things.

The second post in this series is here: Situational Application Brainstorm