17 August 2009
The phrase designer-developer workflow has been circulating for several years now. It describes the relationship that a designer and developer have when creating an interactive experience for the web or desktop. But what it doesn't convey is the interaction between both sides. The term workflow makes this relationship sound linear, when in fact it isn't.
Throughout the life of a project, we all add value along the way. While the project itself might be linear, from start to finish, the actual collaboration isn't. Interactive projects don't lend themselves to an assembly-line workflow; we each add components, pieces, code, or designs until the final product is finished. The process is organic and, most importantly, iterative.
As a group product manager for Adobe, I work with designers and developers who build interactive applications and content. The one thing I often hear is that the workflow among team members is the most critical component for success on any project, and what facilitates a healthy team is clear and effective communication with everyone involved.
In this article, I discuss some of the iterative models that are used in development and design as well as explore how this iterative model can be effectively communicated among your teams.
Iterative development is defined as building functionality over time. For example, when I have a project, I continue to add features, interactivity, enhancements, and functionality—one item at a time.
Let's use a simple game as an example. One key feature of a game is the ability to track the player's score. To add this feature, my first step might be to increment the score of one player through calls to the scoring system. The system might have nothing else associated with it except for adding points to the score. The goal here is for the initial version to be very simple. I can evolve the scoring system over time, adding a small feature or capability at each step, or iteration. Some of the small enhancements I can make to the scoring system iteration over iteration are as follows:
As a developer, I can use this as a feature roadmap for developing specific components, or I can identify next steps after I complete each step individually. I also have a basic idea of where I am taking the project long-term, so I can focus on building each individual feature but architect it in such a way that I am not throwing away work later on.
When I'm building something very large on my own, I don't have the luxury of time to build or define an entire specification for my application. However, I do know what the pieces are, and I can start with something very simple, such as a group of Adobe Flex components, and build out the basic building blocks. Then with individual development steps, I can extend the functionality of the pieces to massage them into the form and function that I ultimately want. After that, I can jump onto another component of the larger application and do the same thing—or jump between different components without needing to make a huge paradigm shift between pieces.
Over time, I am able to build functional modules that I can then integrate to build the overall application. This combination of components is also done iteratively, building communication bridges through events and listeners throughout the modules of the application that are already built.
So how does iteration apply to design? The short answer is that it applies in two ways that you might not think of immediately.
First, when creating the overall design, I start with the basic building blocks: Where is the navigation? Where is the main content? Where do I put this function or that function in the application? These basic building blocks are the formation of the overall wireframe of the site—the architectural plan for the structure and methodology of how the end user will consume the site, application, or content.
The design process may start off simple as you decide on major content blocks such as navigation vs. sections A, B, and C. The process of getting from the former to the latter is iterative design. You continue to evolve and move the design idea further along through incremental steps.
The second method is when I have built the entire overall structure and am ready to build the visual design on top of the wireframe. Now that the user interface has been mapped out, the discrete elements within the structure can be broken out and designed individually. It is important to design the elements after designing the overall structure because you need to know the elements' context within the larger site or application. How each individual piece interacts with everything else will define whether the site or application has a cohesive and fluid user interface design.
So, with our navigation example, I would iteratively design the component starting with its default state, and then I could extend different elements. For example, in my game, I might have a menu bar. When I design it, I can iteratively add design features to the menu design. These steps could include:
With each step, the design of the component (in this case, the menus) needs to work within the navigation; however, it also needs to work in the context of the overall application or site, ensuring that the design and interaction flow well across the interface.
When the navigation is complete, you can continue to tackle the next component element.
One of the nice things about developing and designing iteratively is that if I go too far or if I go down the wrong road, there is a clear path back to a point where I can refine and continue forward.
For example, if the scoring system in the game example needs to be able to decrement the score, I can go back and add that functionality. For a more complex project, if something more fundamental needs to change, I can revert my project back to the state where I can more easily make that change, and then reapply my work to the component and fix any integration issues.
With the design example, if I find out that I need a tertiary level of navigation, I can back up to where I built the secondary navigation, add tertiary navigation, and then move forward again. If I find that the tertiary navigation doesn't work well with the overall context of the site or application, I can dig back further, rework the secondary navigation, and then apply the tertiary level and revalidate.
For many designers and developers, this might seem basic, but it is a fundamental element of how we work and how we add value to our projects. This applies to design disciplines that exist outside of interactive development. For example, video editing is an extremely iterative design practice. Editors work with one clip at a time, and then with a scene, and then with the overall movie. Growing from the individual element to something larger is a key way we tackle even the largest of projects.
With both the designer and the developer iterating in their own way, there comes an interesting dilemma: How can each individual communicate across disciplines to help guide and inform the entire team that's building a site or application?
Part of the answer is to broadcast information with each iterative step; however, this is only effective if each iteration is granular enough for the communication to be valuable. The other necessary component is that the communication is relevant. It may not always be relevant at the present moment in the project, but it must be valuable later in the development process so team members have the information they need along the way.
One theme of iterative development and design is flexibility. As all team members contribute to the iterative process, they must be open to flexibility in their work and the work of others, so they can integrate the various components, designs, and code efficiently at the end. For iterative design and development to work successfully, all participants must be on the same page with the project.
Too often, an application designer and developer start from a detailed specification and then go off on their own to begin the design and development process. Usually, the specification doesn't accommodate all of the use cases of the design or functionality, so they adapt the functionality as they work to meet the requirements. The problem is that the design and development are happening separately—independently of one another—so when the design and functionality meet at the end, they are incompatible with one another and need to be updated to resolve the differences.
Creating a universal language is the first step. At the beginning of the project, the design and development team must agree on the major components of the project. Specifying their function and design isn't required, but agreeing on the major pieces is key. For example, an application might contain a menu, some sort of chat function, and a gallery of objects. The team must agree on common names, basic component roles, and the overall purpose of each major component in the application.
With this common definition of items, team members can begin to iterate their own and their coworkers' contributions to the components. As the functionality is defined, designers and developers can use those definitions as the basis of their ongoing iterations, building out the next steps as they work on the current step. As functionality evolves, the future iterative steps can adapt to meet the updated requirements.
If conflict develops between two parts in an iterative step or sequence, the participants can communicate the differences, resolve them, and move on, without having to rework the entire component, site, or application.
Multiple technologies and systems can help both designers and developers work in iterative ways. For developers, an indispensable technological tool is a code version control system, where each iteration is stored in the repository for future reference, enabling developers to revert back to previous iterations if changes are needed.
For designers, tools such as Adobe Version Cue and other design asset management systems can provide crucial versioning help for iterative development. Even adopting a team-wide file-naming convention for a networked file system can be helpful. There are also design applications for code repository systems, such as Subversion.
For teams, setting up wikis, internal development blogs, and other communication tools can greatly improve communication on all fronts by providing a central point for getting information that can also be subscribed to, which automates the information-gathering process.
The key challenge, however, is that no matter which tools you implement, the entire team needs to use them. Otherwise, the value of the tool is lost. If team members working on one component of the design or development are not aware of the iterative work of other contributors, their components will not be as adaptable or may have integration issues.
Exploring these technologies and discussing them with your team members to determine which would work best should be your first step. Find technologies that your team is comfortable with, and open your mind to different options or tools you may not have considered. Again, the ultimate goal is to get your team to work well together and, as I mentioned earlier, successful team communication and collaboration are what ultimately make your project a success.
For more information on designer-developer workflows, check out some of the design/development and iterative prototyping articles in the Fireworks Developer Center, among others. Also learn more about Flash Catalyst and Flash Builder on Adobe Labs.
Note: This article appeared originally in the Edge newsletter.