We are currently building an application that will help businesses and the people in them: execute on their strategy, work on their businesses and focus on the most important work first.
Over time our process for designing the application and eventually getting to a working application has changed (and it will probably continue to do so as we move forward). My part of the process ends when it moves into source control, HTML and detailed look and feel. I am focused on capturing two main things in this project:
- The underlying business rules,
- The user interface design (or user experience).
Now to be clear; we all use the tools we are most familiar with. If you are filling this role and know HTML/CSS inside and out you may skip from sketching to high fidelity HTML mock-ups like the folk at 37signals. This is a preference and the key is that it works for you.
I start with sketching in most cases. A whiteboard and sticky notes work well for what I am normally trying to do. Here is a sample of a sketch (I had to blur it a bit because I used real client information in my sketch).
In this case I was working through the business logic and not designing user interfaces. We are building a product and not a custom software product. So my goal is that by the time the developers start coding, I can act as the customer because I understand the subject matter well enough. I am also fairly clear on what we need to build so we avoid excessive thrashing in code (which is very expensive).
I have numerous discussions at this point with the developers to make sure I really understand the application (i.e. I can answer questions) and get ideas for what is possible, easy and hard in code. Developers are also encouraged to offer ideas for product improvement.
This part of the process is highly iterative and in no way do we try to spec out the entire application at once. We build part, make sure it works, then add more stuff in.
In the second stage I layout the screens in interactive wire frame mode. The goal is to make sure the business logic is captured, we think through the user experience and maintain consistency with the rest of the application.
I don't get too carried away in wire frame designing. The tool we are using right now (FlairBuilder) allows you to program quite a bit of interactivity, but I prefer to only do enough to work through the business logic and work-flow. I leave the rest to the normal (agile) discussions between developers and the customer which occur throughout. There is no possible way anticipate everything in paper or wire frame; and that would be a step backwards anyways.
Here is a sample (very simple) wireframe. I still plan on doing a review of the Flairbuilder tool down the road with more details about the actual tool.
The next step in the process is to develop the application in code, use it, refine it and repeat until we are happy with it (or until the budget or time line is used up).
My goal with sketching and wireframing is to explore numerous design ideas very quickly and then have discussions with the developers about the options. With this approach we can go through several iterations for a new module or capability in a day or two. In code we would probably be talking weeks or longer.
For me, right now… this is the simplest thing that works.
