My last several posts have been following a personal project of mine, named Charity Tree, and how I am attempting to follow many of the guidelines laid out in Getting Real by 37Signals. This month I had the privilege to attend West Michigan Startup Weekend and was able to put a few of those gems of wisdom to practice, out in the field, as it were.
After the initial teams were formed on Friday night, we had time to get familiar with the project, the team members and the goals for the weekend. For my particular team, we had initially thought that we would be designing a website/web app over the weekend. So early Saturday morning, when we really got down to business, I started thinking about the coding that was going to be needed: database backend, form controls, web service functions, etc. I started asking the team some basic questions about how things would work, started to feel a bit overwhelmed, and then said to myself, “Wait! Haven’t I learned anything? I’m diving into details way too quickly”.
I guess in the excitement, and the knowledge of the impending Sunday deadline, I wanted to start cutting code immediately. But where would that have gotten us? As I look back on the results of the weekend, we wouldn’t have gotten far. At the most, we would have had some functioning code that would now have to be abandoned due to changing ideas and requirements realized.
Luckily, I remembered what I had been blogging about for the past couple of weeks, and decided to put it into practice. So one of the first things I did was follow Getting Real’s Interface First concept (I blogged about it recently). Basically, I needed to start sketching out interfaces, rough-like, to start feeling out how the web app was going to work.
The team started to brainstorm again about how they envisioned different scenarios taking place. I wrote user stories to encapsulate these scenarios. We came up with several wireframes. One is pictured here:
Wireframe
Now, this wireframe may not look like much, but it was interface sketches like these that really made us start to think about how the application pieces as a whole fit together, and more importantly, how processes (both business and application) were going to be carried out.
These rough sketches brought many things to light and really helped us flesh out the project. What did we have by the end of the weekend? Wireframes and mockups. It would have been nice to have some functioning code, but we would have been way off base and throwing away a lot of work. Thinking “Interface First” saved us from going down the wrong road and helped the team narrow in on what was important. The weekend was over, but now we could hit the ground running.
So another new process for me is only thinking about the interface design at the beginning of the project — not how I’m going to code it. Usually, I’d be thinking database schema, class diagrams, coding frameworks, etc. from the get-go. This time however, as throughout this series, I’m using Getting Real from 37Signals as my guide.
Interface First
If you’ve been following along (and if not, I have a list of articles at the bottom of this post), you’ve watched as I’ve attempted to sketch out ideas for some of the most important screens in this project. This is really quite a refreshing approach and it makes a lot of sense. As Getting Real explains, the interface is what the user sees — it IS your product. We can play around with how the app is going to look and feel right NOW and not just slap it on at the end of the project.
Sketching out interfaces and changing things around to see what feels right is a ton easier than rewriting code. We can sketch, create some loose mockups and repeat as many times as we want for minimal cost.
From the previous post, you can see that I roughed out a couple of ideas for one of the most important tasks of this app: matching clients with donors. I want to revisit this task to determine what it is exactly that will need to be accomplished on this screen. Then we will rough out another interface.
Approaches
There are a few of different ways a user would want to approach the matching activity:
Call up the clients waiting to be matched and find donors for them
Call up the donors waiting to be matched and find clients for them
Call up a specific client or donor and find available matches or remove assigned matches
Items 1 and 2 are just reciprocals. You either want to approach the matches from the clients’ or donors’ sides. Item 3 addresses organizations who are tracking possibly hundreds of clients and donors, who want to quickly locate a specific entity.
Screens Required
After a client or donor has been selected from a list or a search, the next screen would show possibly more detail about the selected entity with a list of possible entities to be matched with. At that point, a match can be made. So our screen list for this activity looks like this:
Client list
Donor list
Search
Match
Part of the goal of this phase is to answer the following question for each screen: “How do I know when it’s useful?” So for the matching activity, let’s take it one screen at a time.
Client List Screen
At this point, I’ve decided not to put the client and donor lists on the same screen. There is just too much information for both entities to be able to make informed matches from summary displays. (I’m not trying to think of too much detail here, but I know that according to the organization, some donors may specify things like, “I only want to give give gifts to children under 10”, and things like that. Details like those do not lend themselves to summary screens.)
So how will we know when this screen is useful?
A list of all clients waiting to be matched can be navigated easily
Enough information for each client is displayed for the user to make a decision on whether to proceed with that particular client. Generally speaking, the user will want to know the genders and ages of waiting clients.
Here is the sketch:
Interface concept for client list screen
On the left side you can see the list of clients displaying basic information: the family name (since clients are grouped by family as per a typical application), and the gender and age of each individual. Also shown beneath each individual is an indication of their current gift status. Above the list is a filter bar, where the user can set the list to display only certain ages, genders, or other criteria. A scrollbar is also available to the right. So I think this interface could satisfy the two requirements: navigate the list easily and see enough information at a glance to proceed.
The right section of the screen displays detailed information about the selected client before proceeding to find a matching donor.
Donor List Screen
The donor list screen is similar to the client list in layout. However, the summary information displayed for a donor is slightly different. For each donor, described is any specifically requested criteria about who they wish to give to (teenagers, single moms, families of 4 or less, etc.) and how many openings they have left for each type.
So how will we know when this screen is useful?
A list of donors waiting to be matched can be navigated easily
Enough information for each donor is displayed for the user to make a decision on whether to proceed with that particular donor. Generally speaking, the user will want to know the types of clients the donor is looking for and how many.
Search Screen
I’m not sure if the search demands its own screen (a nice big and bold search box with some suggestions perhaps) or a search box will simply sit in the right section, at the top of both the client list and donor list screens.
Match Screen
After a client or donor is selected to proceed from one of their respective screens, it is time to match them up. Let’s look at a concept for the screen that would display after we’ve selected a client from the client list screen.
So how will we know when this screen is useful?
A detailed view of the selected client is available
A list of available donors is easily navigated
A detailed view of a donor ready to be matched is available
A match is able to be made
Here is the sketch:
Interface concept for a matching screen
The client is the main focal point of this screen with a view similar to that of the client list screen. Immediately to the right, however, is more information about the client. Below the main client view is a list of available donors. These donors all have openings for the entire client family. (I need to think about allowing the selection of one member of a client family at a time here, but that can wait). Each donor row displays summary information for the donor — mainly stats on what type of client they would like to donate too and how many openings they have left. Immediately to the right of the donors is a detailed view of the highlighted donor. If the user is satisfied with the pairing, the match button is clicked. (I’m also thinking of dragging individual client family members down to the openings in the donor rows to make the match).
So this was more sketching, like the previous post, but I put a little more thought behind it this time. “From Idea to Implementation”, from Getting Real by 37Signals, suggests answering questions like “What does this app need to do?” and “How will we know when it’s useful?” that I tried to address this time around.
As you may recall from the last post, we’ve done a little brainstorming, and now it’s time to sketch out our ideas for the interface. We don’t want to draw details. The goal here is to just get our brainstorms on paper. 37signals suggests using big writing utensils, like markers, to force yourself away from the details. We should just be sketching boxes and shapes to convey our rough interfaces to someone else.
Before I refreshed myself with Getting Real, this is what one of my interface sketches looked like:
The wrong way to roughly sketch an interface
Notice how many details I tried to think through here. I tried to plan the exact buttons that would be needed, how a user would navigate through a list, what data would populate a section, and the details of a pop-up box. This was getting way too far ahead of myself. I had the potential of locking myself into an interface before I knew everything I needed. Plus, I used color. I actually wrote another post a while ago where I declared the joy I found in brainstorming with colored pencils. I think that may still have its place, but it should be reserved for further along in this process.
So for this exercise, I stuck to a medium size drawing utensil, and only labeled something in the sketch when it would be hard to remember later what I was actually sketching.
One of the main activities of the charity tree app is to match clients with donors. This first sketch’s intention is to portray a move away from what may be normally thought of in a data matching scenario. The easy, but boring way to implement it would be to have two list boxes, side-by-side, and the user selects data from one box and moves it to the other. Here, I thought of a view of a donor who has openings for more clients. The clients are listed at the top of the screen along with some summary data. The icon for the family is perhaps dragged and dropped into one of the donor’s open spots. This would definitely make the data much more interesting to view and manipulate than dull list boxes or spreadsheet views.
First interface concept for matching clients with donors
This next sketch explores a slightly different design on making the matches. Here I was thinking about interlocking clients and donors like snapping pieces of a puzzle together.
Another idea on matching clients with donors
One of the other key tasks the app needs to accommodate is tracking gifts. This sketch shows an idea of looking at a specific donor, along with the clients that have been assigned to the donor, and a visual indication on the status of each gift (e.g. gifting tag sent, gift received, gift delivered). There could be a summary box at the bottom of the page displaying data such as total gifts assigned versus gifts received. Again, the details weren’t thought of too much at this point; I just wanted to portray a fun interface for manipulating the data.
Concept for tracking gifts
Assuming we are satisfied with these sketches, we can move onto the mockups. But remember! We are not locked into the design at all. This process is about quick design iterations before we commit to the hardcore coding.
Continuing on with fleshing out my idea, we are going to look at “From Idea to Implementation” from Getting Real. This process will span several posts as we brainstorm, sketch, mockup and code.
Brainstorm
Brainstorming is about ignoring the details and looking at the product from a bird’s eye view. Let’s just think about what the app is going to do at a high level. Too many times we can get wrapped up in things like, “How am I going to accomplish this part?” and “Do I know how to do what I’m thinking?” Forget about that and just focus on the end user experience.
Here is what this app going to do:
Accept applications from clients and donors
Match clients with donors
Create and send gifting cards
Track gifts
I have more ideas and more details, but they can wait. If the app doesn’t accomplish these four things, it will not be useful. We will be using this list along with the points made in “What’s the Big Idea?” to make sure we stay on track.
As noted in the introduction to this series, I will be trying to follow the guidelines laid out by 37signals, in their fine book, Getting Real. Recently, I’ve begun to take notes in my Moleskine, on some of their essays, and will share them in these articles. These notes just scratch the surface, so I highly encourage you to read the book, that you may learn as much from them as possible.
The first guideline I will address is “What’s the Big Idea?”, where we push away all of the details until later and get to the heart of the matter. What is the purpose of this app?
Define the one point vision
Manage a charity tree program with ease.
Why does it exist?
Software that handles programs specifically of this type have not been found. Charity tree programs generate a lot of data which is typically tracked with paper and pencil or unorganized documents and spreadsheets.
What does this app stand for?
This app will give charity workers, typically volunteers, the tools necessary to easily manage their charity tree programs.
What makes it different?
Typical, boring, spreadsheet-like tools will not be present in this app. Users will be able to quickly view and manipulate the data that is important to them.
Stay true to the vision
During this project, any feature being considered will have to hold up to the answers given above.
I developed a prototype web app for a charity organization a few years ago that was meant to give the administrators and volunteers control of their charity data through software, versus the traditional paper and pencil method. This project never took off, in part due to conflicting goals within the organization, lack of communication and most of all, my lack of experience at that time for maintaining a project capable of producing a reliable product and which could weather the storms of continual client change requests.
Times have changed, I have more experience, and I’ve been influenced by many great developers. I’ve been aching to take what I’ve learned and apply it to a product development project. I’ve decided that the charity project is a prime candidate for testing my new skills and ideas. The project started as a one-off, tailored-to-a-client application. I am changing the direction of the project to delivering a product that will work for many charity organizations dealing with the same types of issues.
What is a Charity Tree?
This project addresses “charity tree” programs run by charity organizations. These programs, usually run during the Christmas season, identify persons and families that are in need of help, then match them up anonymously with donors.
Many churches run internal programs of this type, where things like ornament tags are placed on a Christmas tree with ideas for gifts for a certain type of individual. A donor then takes a tag off the tree and will purchase a gift for the unknown individual. Behind the scenes, people are keeping track of who the recipients and donors are, which gifts have been delivered and a myriad of other details.
A charity organization will run the same type of program, except the number of applicants may be much larger and they may have other requirements as well, such as reporting some of their data to another organization. The people I worked with still did all of this pretty much by hand, which required an enormous amount of volunteer hours. The following tasks are an idea of what is involved in such a program:
Accept client and donor applications
Edit and follow up on applications
Match donors to clients based on several criteria
Track gifts outstanding, received and delivered
Send anonymous gifting cards to donors
Send reports to other organizations
The Product
The resulting product will be a web application that gives people within the organization easy control over the charity tree data. I envision an installable application (like WordPress) that will live on a web host.
Clients and donors will log in to fill out applications. Those without access to the web can turn in paper applications to the charity, at which time a volunteer could enter the application into the system.
Application users will have varying levels of access to the data including creating and editing of applications, matching clients to donors, tracking gifts, etc.
The goal of this software is to provide charities with an easy way to manage their program while being fun to use at the same time.
The Project
The guiding principles for the project are laid out in the fantastic book, Getting Real, by 37signals. My intentions are to follow their advice as close as I can. Two of the main objectives are:
Keep the application simple
Make the users happy
I will be posting progress on the project here and sharing my processes as I strive for these two goals.
