Taking a Step Back, Defining Users, Uses, and Building a Wireframe

I've gotten to the point in writing my Project Management web application, Unity ™, that I'm making decisions about functionality and features while I'm writing code. In my opinion, this is a bad thing. A really really really bad thing. Having your IDE open while you're trying to figure out what the application should do is scary. You could end up with a ton of code written that won't ever be needed. Or once you're finished coding a feature you realize it's not that great, and you scrap it.

I spent the first 6-8 months of working on Unity ™ doing three things. Learning Java, figuring out how to store a tree structure in a database, and building a prototype.

(I define a prototype as all the screens of an application fully "mocked-up". The mocked-up screens display all the features and movements of an application, but they don't actually do anything. They are just dummy screens.)

All three activities were worth it, but I made a mistake in regards to my prototype. I built a prototype that I thought was about 80% complete. It had all the major pieces. I told myself that the other 20% of what I needed to implement I could just figure out as I built my app. I had all the details in my head anyway.

The problem is I skipped a few steps before the prototype. That "80% complete" has turned out to be only about 50%. And it's not that great of a 50%....

Here is what I skipped.

1. Writing out, on paper (or a word processor), EXACTLY who will be using my Project Management application. I had an idea, and I kind of knew the market I wanted. But "kind of" doesn't force you to think about the features you'll need to make your product a success.
   
2. Writing out, on paper (or a word processor), EXACTLY how the people using my Project Management application will use it. Again, I had an idea. But without it spelled out in black and white I never forced myself to think about all the features.
3. Building a full and complete Wireframe. I built a Wireframe that had all the major pieces, but I did it in the same "80%" fashion my prototype was done in. (i.e. - It wasn't done, and that 80% was more like 50%.)
   

(You can use a specialized tool, like Synthis's Adalon, or a generic diagramming tool to build a Wireframe. Visually, a Wireframe is a bunch of boxes with lines connecting them. Each box is a screen and each line is link between the screens. The link can be a hyperlink, form submission, or any other action that brings the User from one screen/screen state to the next. Each box has a description of what is on the screen.)

I really should have known better.

Over the past couple of weeks I've been working on a few things. Defining my Users, writing a story about how they will be using my application, and building a wireframe. These three activities have really focused my mind on the application I'm building. I've honestly discovered a couple of features that I must implement, and I've realized that I need to change direction on another major feature of Unity ™. (I'm intentionally not writing about what they are because I'm not close enough to shipping the product.)

Here are some tips for defining your Users and writing out how they use the application.

• Don't force your self into a rigid, "I must define all the Users before I write about how they use the application," mindset. Allow yourself to flip between defining what the Users are doing with the system, and who is using the system.
  

• After you define a few Users, write a story about them using the system. Do NOT write a feature list. A story about the Users interacting with the system in a typical work day will create a far more accurate needed-for-launch feature list than just typing out: Create Project, Create Task List, Assign Tasks, etc....
  

• Make your stories about the Users fun. Who cares if it takes an extra 3 minutes to write something like this:
  

"Monday morning rolls around and Peter shows up around 10:00 am. He slept in because he spent the weekend in Mexico getting drunk off cheap tequila.

Peter logs into Unity and notices that he's working on a Project called, "Skinny Jeans Product Launch Web Site". "Wow!", Peter says. I don't remember that Project. (Apparently when you mix cheap tequila with expensive mouth wash it affects your memory.) Peter sees that he completed writing a Site Definition for the Project and that his Client's name is Mary Client. Which he finds ironic, because she is his client. He also sees that he left himself a note to get started on the timeline."

As opposed to:

"Peter arrives at the office. Logs into Unity and sees a note to get started on a timeline for the Project."

You're going to be referring back to your stories at some point to extract your feature set. You might as well make that second read an entertaining one. (You'll remember the stories a little easier too.)

When I started mapping out my screens in my Wireframe, I literally read a few paragraphs of the story and made the Wireframe screens to match. Keep in mind that I've already coded a bunch of screens for my application. But while performing this exercise I realized that some of them may need to be tweaked. Since I'm taking the time to go back and create a real specification to build from, I'm not afraid to change things for the better.

To help you understand Wireframing a little better, here is an example of a Wireframe screen description. (NOTE: This isn't the actual description of my "New Project" screen. I've got to keep some of this stuff under wraps.)

Display form w/fields (# means required)
-*Name of Project
-Select List of Clients

If this form is arrived at from inside a Client Detail screen, then the cooresponding select list will be prefilled and marked inactive. (I.E. Can't be changed.)

This form can also be arrived at using a Global Command. The select list will be prefilled if the user is working within a Client Detail screen, but the select list will NOT be marked inactive. (It may not have been the intention of the User to use that Client, but it is nice to prefill them since that was the context they were in.)

This form will also have a button labeled "More Details". When clicked will open up the following form fields:
-Project Start Date (defaulted to today)
-Project End Date

When building a wireframe, I like to keep the descriptions short. At this point I'm just listing out what each screen will have on it.

I try to keep the User definitions, User stories, and Wireframe real loose at this point. Don't be afraid to make radical changes. That's the point of the exercise. You're figuring things out, not writing requirements for programmers to write algorithms from.

In my next blog post I'll talk about Prototyping and detailed Requirements. I'll also cover where I think you should really lock everything down.