In web development design is often the main force driving the project, then comes content, functionality followed by technology. Sure, the first thin the visitors see when they come to a web page is the design of the start page. In 3 seconds the visitor has judged the site by the look and feel of the site. The way the menu is composed, if the information they seek is one of the first things they see, and so on. The first page tells you much about what you can expect of the web site. But what happens after that?
When working with small to midsized projects much effort is put on the design, the look and feel of the site. The start page is carefully put together, and then the main pages are laid out. The designer delivers some pages containing the big picture. Of course the design is flawless, all pictures align, the articles are just the right length, and tables are static and so on. And when you get the designs everything is just perfect, until you start coding. Questions start creeping upon you, first there is just a question like “how do I handle this content if the editor doesn’t provide the content”, in this case you could just not display the control, but then the design may break. Once you tackle that minor design bug you jump right to the next task, a data entry form. Again the designs is beautiful, without error messages or follow up screens, and yes here is when the next question you already knew would come “what should happen if there is an error when posting this form”.
I suppose you already guessed where I’m going. More often than not, designs (and also requirements) are like Swiss cheese, nice and round on the outside but filled with holes when you cut them open. They lack all those things that must be in place for the user to have a good user experience and interaction with the site. So there you sit, in front of your screen, having to make a on the fly design decision, one of those things programmers sometimes shouldn’t be allowed to do.
So how do we get through this? There are several ways to tackle this dilemma; the best would be to educate the designers so that they also take interaction design in consideration when creating the UI. Or even better, to have a designer with web coding background and/or a genuine interest in web. But that’s not always the case.
A quicker one is to have a dedicated and experienced interaction architect. A person that thinks in personas, work flows and creates wireframes for others to follow. A person that creates use cases that follow a red line thru ought the entire design and workflow, and that can be used to test the application with automates UI tests.
The role of the interaction architect is far underestimated, they not only facilitate the work of the designer by giving them a rough canvas to get started from, but they also fill all those holes in the cheese. And when those interaction gaps are filled the work for us programmers get so much easier, not just because all those questions get answered but because we can focus on our part. Create great code, good UI tests and the best part, we don’t have to do the work that someone else would do so much better.