Iterative Design In WebWiz@rd
You may have heard of this term before, especially if you frequent the social circles of graphic designers and user interface developers. Here at REM, we apply the iterative design process to our work on WebWiz@rd. I'll spend the next couple of paragraphs explaining what exactly iterative design is, and then I'll explain how this benefits our customers who use WebWiz@rd.
Since I don't believe in reinventing the wheel [It just works! Right?], I'll quote a bit of Wikipedia's entry on iterative design:
"Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a product or process. Based on the results of testing the most recent iteration of a design, changes and refinements are made. This process is intended to ultimately improve the quality and functionality of a design. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented." -- Wikipedia (http://en.wikipedia.org/wiki/Iterative_design)
That seems pretty straight forward, right? Maybe not. The problem with the term right from the start is that it includes the word "design". Most people will immediately shift to thinking about artwork or graphics. These people aren't entirely wrong, but the word is still misleading. The "design" in iterative design both implies the look and feel (the user interface) of a system as well as how the system is intended to respond when that look and feel is interacted with. In other words: the iterative design process can be applied to not only the colour of a button or its position on the screen, but also to the conveyed purpose of that button to the end-user.
A web page has two buttons on the screen. One button starts an operation such as a stop watch counter. Another button stops the operation that the first button started. The first button is red (the start button) and the second button is green (the stop button).
Do you see the problem? Maybe it isn't a problem at all to you? If the developers of this web page were to present the page to a set of unbiased users, some might complain that the colours of the buttons are misleading. "Red for go? Green for stop? That's ridiculous!" some of them might cry. Of course, some of the users might enjoy clicking a bigger, red button to start the operation because they dream of flying a space ship. Okay -- I hear you -- this explanation is getting a little silly, but you can see what I'm getting at here. The red and green colours themselves are good choices, but their application is the problem in this scenario. The majority of people might expect "start" or "go" operations to be coloured in green, and the related stop operations to be coloured in red. The iterative design process would catch these complaints from users and would help the developers create a system (a web page, in this example) that fits the expectations of the majority of their users.
Iterative Design at REM
At REM, we practice the iterative design process without ever having to speak of the term itself. Our development and design culture at REM forces us to use this process every time we create something new for WebWiz@rd. New modules are put in front of our customers almost immediately after exiting the beta stage and we almost always get instant feedback on how these modules behave for our customers. Our support team sends us bug reports and usability concerns the moment things break down for anyone, giving us the ability to quickly fix problems and get the updates in front of our customers right away so that they can keep working and continue to provide feedback on the usefulness of our changes.
This isn't to say our customers are the first human beings to interact with new parts of WebWiz@rd. Our support team is tasked with hammering our new systems with every possible scenario they can think of. They do their best to try to break down our systems so that our customers don't come across major flaws in their own work flow. Our support team does an amazing job of unearthing both the smallest and largest of design flaws in our systems. The developers, in turn, fix those problems right away and get the changes back in the hands of the support team so they can continue to hammer away. It works, and it works well. I'd hazard to say 99% of bugs and confusing interface problems are removed from our system before our customers ever see a single, new screen. That's saying something!
Time To Reflect
I'm very proud of our team at REM. We work really well as a team, but we also know how to approach our own work with an outsider's perspective. This definitely helps us improve our products through the iterative design process and we have an amazing set of technology to show for it.
Do you work for a company that practices iterative design? We'd love to hear about it in the comments or feel free to drop us a line any time.