I’m an Interactive Creative/Developer. One of my differentiators as an Interactive Designer is my understanding and abilities in development. I write HTML/CSS at an expert level and write javascript using the jQuery library at an intermediate level. My knowledge and abilities in these areas help me create unique User experiences. The following is a run down of my creative process, planning, designing, and development methods.
Whether I have a new project/client or not I feel that learning & looking is paramount. My Google Reader and Twitter keep me abreast of the designers and design magazine/blogs I follow. I like to read about new techniques (both visual and technical) as well as look at hundreds of pictures everyday. You can see a documentation of the images I find inspiring or representative of my aesthetic in my Visual Stimulation project or my Flickr account.
When starting a new project I believe that listening is my best asset; listening follows observing which leads to communicating. I prefer to speak simply with co-workers or clients, avoiding getting too technical or throwing around unnecessary buzzwords. I go so far as ensuring the use of contractions to establish a sincere and personal tone.
I believe that the interactive design process begins with identifying the problem or defining the project/effort. By collecting as much information as possible at the beginning of a new project you equip yourself to the best of your abilities at an early phase. I like to start with a Creative Brief, a set list of questions I’ve developed that help me extract the information in a uniform and thorough manner.
Once I’ve gathered as much information as I feel is available or appropriate I then proceed with designing the Information Architecture of the site/project. I feel that any steps skipped in the early stages of a project only tempt the fate of the later stages and can have huge and sometimes drastic effects. By defining the Information Architecture you ensure that both client/co-workers are on the same page of what the project will consist of. Also, it avoids confusing Users when they’re using the site/project or getting stuck at dead ends. I use Omnigraffle to design my Information Architecture documents. They end up looking something like this:
Following the Information Architecture I then proceed to Wireframes. Wireframes are documents the depict only where information will be presented on the page/screen. There are no visual/design elements or content involved. In my experience it’s slightly difficult to explain to clients that Wireframes are only a representation of the placement of information. Clear and simple communication effectively gets the message absorbed. I generally Wireframe the homepage as well as 2 to 3 of the major interior pages of a site/project. After that everything else seems to fall into place as a natural progression. Here’s an example of what my wireframe documents usually look like:
I embrace the agile methodology of design and development which means that I’m willing to work toward the final solution. I accept that everyone will try their best to define and work towards the best solution from the start but embrace the possibility of the final destination changing a few times along the way as new information or challenges or ideas arise. Despite all of the variables that are bound to occur from the start to the end of a project the next step in my process after Wireframes is the visual design. I use Photoshop to create non-functional graphical representations of the solution. These visual mock ups usually result in multi layered documents that require a high level of organization. Here’s an example of the layers panel for one of my mock ups:
The design process, as well as the Information Architecture & Wireframe steps, usually include a revision or two from the client to get it right. I’ve found that by communicating a specific number of acceptable revisions helps focus the project on advancement and progression. Once the visual design is clearly presented and agreed upon the development phase starts. Development generally takes as long as the first few phases combined. It’s the time when all of the conceptual and visual work is translated into standards compliant code. I have been using WordPress for years now and find that it’s a great solution for most websites. WordPress is a highly customizable CMS (Content Management System) that allows Users with sufficient accounts to log in and add or edit content very easily.
At regular intervals during the development phase the client or team will be presented with working versions of the site in it’s unfinished state to use/test/interact with to see if it’s intuitive and working as planned. If there are any suggested improvements or new concepts or ideas of functionality they will be considered and implemented upon mutual agreement.
I use GIT version control during the entire development phase. Version control allows you to keep track of your code changes and in the event of wrecking or losing a large part of code it makes it incredibly easy to go back to the point where the project still worked … another common version control platform I’m familiar with is Subversion or SVN.
Once the development phase is complete the data entry or content population phase can be done at the same time as debugging. During the debugging and content population phase the project is still subject to change albeit only if absolutely necessary – hopefully due to the planning and organization at the start of the project this is unnecessary at such an advanced stage.
Finally deployment is reached – this is where the ship is launched into the water. I prefer to start with a “soft launch” which means putting the project live but giving it a little while to be used by a select number of Users. These Users are encouraged to give feedback regarding their experiences and if any of the feedback will clearly improve the project then the development team will implement the appropriate changes. The final version of the project is then launched and announced to the word!