Graphic Design with Application States in Mind

Within any software development team if we want to generalize we can almost always group the team members into three kinds of specialization. The first is the hardcore application engine developer. These are the people who write the heavy application logic and processing. They focus on engine development and software optimization, basically the kind of things that only the people that have the knowledge understand. Obviously what this group do is essential to the business as this is the engine after all.

The second group would be the user interface development. These people deal with human interactions with the system. These days this group of developers would deal with building JavaScript heavy application that can provide seamless user experience. This team “shields” the users from the complexity of the application engine. Again this group is equally important in the software development team.

The third group is the one that we are going to talk about briefly today. They are the graphic designers, the artist that brought out designs and ideas to be implemented by the developers. In the past, their job have mostly been creating good looking and usable design for the customers to consume. Creating eye candies that would lure customers away from the competitors into using our software, what ever the software is.

Graphic Design for Websites a Few Years Back

If the world of web development stays with creating static website and simple CMS driven websites such as Joomla or Drupal websites; the graphic designers’ workflow would have stayed the same. That is: create a static website design using Illustrator or Photoshop, get it signed on by the customer then transfer it to the web development team to build.

A lot of the times, the design would be simple one pager with lots of graphics and buttons to slice. Of course I’m not saying graphic design is easy, on the contrary I wouldn’t be able to come up with a revolutionary design such as the “rounded corners” or the “flat user interface”. No, I would have come out with normal acceptable design, perhaps something like this website.

I am able to say the above, because that is exactly what I had gone through a few years back. The web is filled with company websites, booking websites, blogs and static informational websites. There were not much necessity for the graphic designers to think about various states of the application.

The Websites are Evolving

Nowadays, websites are no longer the same, they are now web applications. On an interactive website, every single user interactions requires different user interface design. Basically when the state of the application changes, there must be a user interface design to handle it. Let’s take one of the most popular interactive website, facebook. It’s easy to take for granted that blue bar design of course, but beneath all the simplicity, lies the complexity of the graphic user interface design.

As a simple scenario, the design for a person’s profile page when that person is your friend or not a friend would need to be different. There will be elements that cannot be viewed such as shared photographs or their connections. Also if you are logged in then there will be differences in the user interface when you have facebook chats happening or when you have live friends update turned on.

To put it bluntly, old school graphic design process will not work at all. Designing user interface elements to look pretty without considering different states of the application is not only foolish but also adding time to the software development process due to unforeseen user interface behaviour.

I have been in a situation where the graphic design team provided this beautiful website design. Everything seems to fit perfectly in the design, menus are laid out properly and every single things just fit. The problem is as I mentioned previously, nobody seems to think about the application state. When the contents of the menus are too long, the design exploded. The website’s menu looks bad and re-design was needed. This is not anyone’s fault really, the designers provided great design and the developers built upon them, however the unforeseen happens. So what we need to do is to know the unforeseen situation. To be graphically prepared for what application states can happen.

Designing with Application States in Mind

As a graphic designer, one must almost look into the future what the user might do with the website. Making a list of use cases has never been more important than ever. Every single thing that we allow the user to interact must be catered for. Every single data that might be presented differently on the user interface must be catered for. Gone are the days where website graphic design is simply an artistic exercise. No, website graphic design is now almost like an animated movie making exercise, every designers must know and expect what the user interface is like after certain interactions.

Flowcharts

Using flowcharts to predict the application states is a good start. Not everyone is familiar with state diagrams (which of course depicts the state of the application), however flowcharts are easy to understand. Start with one application state and proceed with adding possible user interaction or data displays. This way we will be able to understand what kind of designs needed to be built for different states of the application.

Storyboards

Ever seen an animator create scene per scene storyboards? This is exactly what the animators at Disney do in order to develop their characters and the movie  scenes. In modern web application graphic design, I think this is what needs to be done. Creating scene by scene design of when the application state changes represents the flowcharts that was created previously.

For example: when a user mouse over a button, we have a design for that. Then after the user click the button there must be a design for that and so on. As much as possible there must be representative design for as much as the states as possible.

For the sake of illustration, let’s pretend we are making a graphic design for an RPG game when the user customizes their character.

In the example above, the storyboard would depict clearly which parts of the user interface needed to change when the user clicks on either “inventory” or “missions”.

Obviously this is an overly simplified example. However in a large complex application, creating storyboards while it can be tedious, will help reducing confusion and frustrations during the life of the project.

Wireframes, do we Need Them?

I think if we have employed both the flowcharts and the storyboards, we do not need wireframes during development anymore. Most of the times wireframes are handy for proof of concept early in the process to demonstrate to different stakeholders of the project and that’s all. Wireframes are useless when developing highly interactive application, simply because its contents are generally static and will not be able to demonstrate different states of application and data.

Remember that now we have advanced web console and debugging on modern browsers such as Chrome and Firefox. There is nothing stopping us from developing the designed user interface in-browser and tweaking as we go using the web development consoles. I know this claim might be controversial, but I simply think that instead of creating wireframes we should create prototypes instead.

Conclusion

To conclude today’s article on Graphic Design with Application States in Mind. When coming up with graphic design for an interactive website or application, always remember that every display contains multiple states. Every set of data will produce variations in the display. Every user interaction will require different design for the display.

In order to tackle these states, it is best to come up with a thorough plan on how to handle different states in the application. Using flowcharts and storyboards we will be able to design for these different states and be prepared to handle them. This way, the development cycle will be faster and the user interface development team will not have to assume or second-guess what the application display must look like in any given state.

Categorised in: Business Process, Web Design