Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. In this article I share one iteration of an evolution of web application design layouts for PlaybookIQ.
I set up a flickr photostream to show screenshots as they evolved. Read the rest of this blog entry first, and then go check it out.
Key points of visual design for web applications stated as expectations from people using your application:
- Proximity: items near each other are related to each other..
- Relative size: larger elements are more important.
- Relative position: elements to the top and left are more important. Elements to the bottom and right are subsets of ‘parent’ elements above and to the left of them.
- Consistency: consistent fonts and colors make an application feel more reliable and well constructed.
- Inconsistency: an occasional inconsistency should mean that something is important or needed to be called out for some reason (e.g. red text when all other is black).
- Persistent elements like ‘home’ or ‘search’ provide confidence to roam around knowing they can always get back to familiar territory.
- Sign posts: let people know where in the app they are.
- Alignment: an application in which elements line up neatly vertically and horizontally feels more professional, is more trustworthy, and easier to use.
- Whitespace is easily understood as way to separate elements that are not directly related, while a line, shading or other elements must be processed by people scanning a page.
- Context is critical. Metaphors like tabs, sign posts, and grouping help people understand what to expect at a given point in the app and helps people focus on one thing at a time.
- Choice is painful and slow. People simply want to get something done. People do not want to be asked to perform the work of making choices. Keep navigation and activity choices to a minimum.
Refreshing But Professional
In a B2B app such as PlaybookIQ, my design goal is to offer a refreshing, yet still professional experience. I do not want to get too innovative or revolutionary and design and development time to create a wow factor could be better spent on additional features that make people’s professional lives more productive. So, you should expect to see common design decisions here.
A Case Study
This series could be subtitled ‘A “Designing the Obvious” case study’ because it follows along with suggestions made by Robert Hoekman Jr. in his book. Click here
Screenshots on Flickr
For the rest of this blog entry, I have set up a flickr photostream with a description on each photo in that outlines the thought process behind the incremental change from screen shot to screen shot. I put the screenshots on flickr because I like the way you can page through them and it is easy then to pick out the changes from screen to screen. If I just listed them here, readers would be scrolling up and down to compare one screen shot to the next.
Click here for the photo stream. You can leave comments on this blog entry or on flickr.
Synap Software, LLC 
Do you find yourself developing the website template before code or vice-versa? Do you design the DB Schema first or process?
Here’s the order I prefer:
1. Understanding of the people that will use the app
2. Understanding of their needs
3. Processes that could meet those needs
4. Goals of the interface (e.g. ease of use, speed, flexibility, cool-factor, etc.)
5. Website templates
6a. Code design (e.g. objects, methods)
6b. DB Schema
7a. Test cases
7b. Code
Using Rails (and other frameworks that abstract an object layer from the persistent data stores), defining the DB schema and defining the overall app design are done at the same time. For example, I know I need a contact model, a task model, a user model, a comment model and others. In Rails, it automatically follows that I will have a “contacts” table, a “tasks” table, a “users” table, a “comments” table and others along that convention.
I haven’t made it clear (like step 1, 2, 3, etc.), yet I am trying to publish the posts in this series in roughly the order that my project goes. I might go back, package them all up when done, and make it obvious that this is a step-by-step series.
Someone very wise once said “criticize by creating” so here is my feedback:
“http://www.volcanicmarketing.com/playbookiq.gif”:http://www.volcanicmarketing.com/playbookiq.gif
Melvin – Thanks for the feedback and for taking the time to create a mockup. I like how you have simplified the look and will take that into consideration.
I can’t take full credit. I derived the design from the HighRise system… adding features and moving a few things here and there.
I’ve posted a few new shots of the current UI approach.
I found that after reducing and reducing, I ended up with a minimalist approach, to be sure. But it just had no life and were not screens that I wanted to spend time on.
The current approach is a good balance – just enough and not too much.
Also, as the code is being written and tested, I have started paying more attention to how many clicks it takes to do something. To reduce the number of clicks often means exposing more choices at once, which is a worthwhile trade off.
You can see the latest mock up on Flickr “here”:http://www.flickr.com/photo_zoom.gne?id=840179061&size=o.