I Love it When a Plan Comes Together (80's pun intended)

We're developing a web application for a client, and I just wanted to share the planning process for this particular application. By no means is this meant to be a 'that's the way to do it' kind of post, but hopefully some people may find it useful. We'd welcome some suggestions on how we can improve this process.

User Goals/Actions

Simple or complex, it's vital that users are identified, and goals/actions for these users are clearly documented. After all, who wants a website that doesn't do what it is meant to?

For more complex sites and applications, it may be useful to write User Stories, sort the Users into logical groups and then sort the User Stories in order of importance so that goals with the most Return on Investment (ROI) can be prioritised in the backlog and design.

A User Story goes something like this:

• User
• Goal/Action
• Why you would want them to complete the Goal/Action

Here's an example:

• New Customer
• Fill in Contact Form
• So we can contact them for a sale

At the end of this process, you should have Users, logically grouped, with their appropriate Goals or Actions assigned.

Now everyone involved in the process knows what is expected.

Data Modeling

The first step in our data modelling was to identify each 'model', a model being a logically grouped collection of data. In our application, this was things like User, Company, Project etc.

Having identified the models, we then identified each individual element of data, say first name for the User model, and applied a database type and input type to it (with any options), which would be handy for when we came to build the relevant forms. Here's our complete User Model:

• user_id (primary key, auto increment)
• company_id (foreign key reference to Company Model)
• email (used for communication and login) (varchar, text)
• password (varchar, text)
• firstname (varchar, text)
• lastname (varchar, text)
• department (varchar, text)
• tel_no (varchar, text)
• role (varchar, select (superadmin, admin, user))

After that, we defined our relationship between the models, for example:

• Company has many Users
• User belongs to Company

We felt that this was all that was needed to start building the database, and preparing the form views for the application CRUD (Create, Update, Delete). However, we did produce an ERM diagram of this information, but to be honest, that was overkill, and caused confusion amongst the non-technical people involved in the project (I can see it would be valuable for highly complex applications though).

Web Application Modeling

This is where everything gets visual, which can confirm everyones understanding of the project, and how the application will work. The chances are, this isn't going to be an exact model of the finished application, as CRUD actions will be moved around during the process, so that they fit logically into the workflow.

Our main aim was to sketch out the views, and their associated actions for each of our user types. We chose a simple workflow layout, rectangles for views, ovals for actions and chose green, blue and red for our users (users, admins, superadmins respectively). This essentially mapped out our application, and showed what level of access would be allowed to view them and perform the actions. This is where the bulk of the client understanding came from, and was actually the most time consuming part of the process as it acted as a catalyst for various client changes and requests. This was a good thing, it meant we could change the application without having to refactor code or design.

Here's an example Web Application Model:

Wireframes

These basically confirmed our understanding gained from the Web Application Modeling process, and then allowed us to layout the necessary information for each view, without design getting in the way. Having an asset that contains layout but no design allows users to concentrate on the important things like information hierarchy, without getting bogged down in 'subjective' design assessments.

Backlog

It's at this point we produced the Backlog. This was simply a list of tasks to achieve our aims. We could group these into stages if required, and develop quickly with multiple iterations if we wanted to get 'agile'. If not, we could just complete the list and deliver the product to the customer.

I love it when a plan comes together!