Designer-The iterative pattern in the developer workflow

The term designer-developer workflow (Designer-developer Workflow) has been popular for several years. It describes the relationship between designers and developers in creating interactive experiences for Web or desktop applications without expressing interaction and collaboration between designers and developers. The term workflow makes us think that the relationship is linear, but it's not actually.

Throughout the lifecycle of the project, we continue to add content to the project. The project itself may be linear from start to finish, but the collaboration between project participants is not. Projects that require collaboration will not become an assembly line; Each of our participants is likely to continue to add components, features, code, and design to the project at the end of the project. This process is organic and--more importantly, iterative.

As a product department manager for Adobe, I often work with the design and developers who build a variety of interactive applications and content. One thing I've often heard in this process is that "the work flow between team members is the key to the success of the project, and the way to effectively reduce the difficulties that the team may encounter is to ensure clear, efficient communication among everyone in the project."

In this article, I'll discuss some of the iterative patterns that can be applied in development and design work, and show how to leverage these iterative patterns to achieve efficient communication within the team.

Iterations

The so-called iterative development, can be defined as the entire functional building. In a project, for example, incrementally add new features, interactive experiences, feature enhancements, and new features-just one at a time.

Let's take the example of developing a simple game. A key feature of the game is to record the player's score. The original version of this feature may simply be to add a score to the user by calling the scoring system's capabilities. The scoring system does not add points to the user at the given point, and there is no other function, the goal is very simple. In the whole process of the project, we can gradually evolve and improve the scoring system, each time adding a small feature or function, that is, one iteration at a time. For the scoring system here, the various features and features that we can incrementally increase by iteration are:

By calling the scoring system, you can score one point at a time for a player

By calling the scoring system, you can score a player by the number of points per variable.

Score to achieve a predetermined full mark, let the scoring system inform the game

When the scoring system is created, you can customize the score

Create multiple scoring system instances for multiple players

As a developer, I can use this as an "attribute roadmap" for developing a component, or it can be used to mark the next step after completing each step of independence. This allows us to focus on the building of each individual feature, even if the project cycle is long and we know where we are. Designing the entire development process in this way ensures that we don't miss any work at some point in the future.

For large projects, I may not have enough time to define a complete application Specification document. But I know what it's all about, and I'm going to start with a simple one, like a set of Adobe Flex components that I can start by developing these most basic components. In each of the next separate development steps, I can extend the functionality of the completed feature slices and integrate them in the form and function that I ultimately want. After that, I can do the same to deal with other components that are similar or not very different in this big application.

So, eventually I can build all the functional modules and then integrate them to form the entire application. The organizational integration of these modules can also be completed by iterative method, through the event, listener, gradually build a communication bridge between these modules.

Design

How do iterations apply to design? The simplest answer is that there are two ways to apply--you may not immediately think of it.

First of all, in the overall design of the system, I start from the basic building blocks (building block): Where to implement navigation? Where is the main content? Where does this or that function in the application be arranged? All the basic building blocks together form the overall framework of the suite (the overall design of how the end user uses the suite, application, or content structure, methods).

The design process begins when you set the main content block of the system (such as navigation, Widget a/b/c). In this process, each completion of a basic building block design, is an iteration. Throughout the process, you can gradually evolve and refine your design intentions.

The second method applies when I have completed the overall structure of the application and is prepared to visualize the design on this basis. At this point the user interface has been determined, the structure of each discrete element can be taken out of the independent design. It is important to design the overall structure and then design its constituent elements, because you need to know the environment in which each constituent element is run throughout a large suite or application. How each independent function module interacts with other modules determines whether the user interface design for the suite or application is relatively fixed or relatively variable.

For example, the navigation example above, I'll design this component iteratively, start with its default state, and then extend the introduction of other elements. Let's say I need a menu bar in my game. When I design it, I can iterate through the design of various features, which can include:

The initial navigation state is designed, and mouse interaction is not supported.

Supports mouse suspension movement.

Supports mouse hover movement and prompt box.

Support the mouse to click on the level of navigation elements.

Supports level two navigation.

Supports mouse hover movement in level two navigation.

Implement the complete navigation structure.

In each step, the design of the component (that is, the menu in this case) needs to be considered in collaboration with the navigation structure, and it needs to work in the entire suite or application environment, so that its design and interaction processes must be adapted to the environment.

Once the navigation structure is complete, you can find a way to deal with the next component element.