Simple software design process
I was recently asked to provide a client an application that would allow users to upload their photos to a web service, and then have an application that would allow users to compose a photo album, or calendar, or other kinds of useful products from their photos. There are of course many ways to achieve this, and it has also been done many times before, so I had the advantage of not being in a pioneer position. I researched the most promising of the existing applications that were designed for this purpose, but found out that none of those were intuitive, easy, quick, nice, scalable or user-friendly. They were just solutions that provided the basic set of tools for the user to technically achieve the outcome, but no help and no guidance for the user to achieve what he or she was actually after, which is a nice looking photo-album.
So I decided that it's better to design and develop the software myself than to use some half-thought engineer type of solution. I started the project by considering the average user's ability to design and compose a nice looking and stylish photo-album. I found out that there are users that have little or no eye for visual design and layout, and then there are users that are proficient in making neat layouts and compositions. There are users that are motivated in using hours or even days composing the product, and there are users that want the process be very quick and effortless. And then, of course, there's everything in between. After a while of thinking I came to conclusion that targeting the application for the "average user" means that it's not probably going to be the best solution for any user.
At this point the thought process came down to a simple math. If I take an equation (the user interface solution), and test it with values 0% and 100% (both ends of the user proficiency/motivation and other parameters) and it works, it probably also works for every value in between, and this gave me basically just two user groups for which to target the solution. So I decided to combine both a quick, easy and effortless way of achieving the desired outcome, as well as a complicated and time-consuming way of achieving a high accuracy of the user's desires. The hasty users can answer couple of simple questions (which kind of covers, which kind of background, which kind of frames for the photos), and the system would layout the album automatically. (The task of automatically placing arbitrary amount of photos on a finite area in an aesthetically pleasing way wasn't too easy, either, but that's another story which I may post a separate post later.) After that, the more studious users can alter the way the photos are laid out, add effects, color correction, rich text and whatnot, but at this point, the hasty user already has a relatively stylish album ready.
So the process of making great Flash applications is not just about programming. It's also about always taking the user's abilities, desires and motivation into account when making the decisions about what the final application should be like. This is, of course, true for every other type of application development, but as Flash is relatively new platform for developing actual software, and the possibilities are truly endless, a good developer should always carry great responsibility for the user experience and not let the bad ideas get through to the final product.