Designer Developer Workflow - Part III

Author: Richard Griffin
Blog : http://blogs.conchango.com/richardgriffin

Expression Newsletter, subscribe now to get yours.

Part I – we talked about project structure and the creation of the application.

Part II – we talked about using Blend from a designer’s perspective

In Part III we are going to cover off some of the workflow details, introduce a new role called the integrator, and take a look at how the different roles in the team work together. We will also investigate how XAML and the available tools are leveraged by the roles in the team.

Previously, when building a browser application or windows client application, the majority of the teams did not include a designer. The developer was solely responsible not only for the underlying layers of the UI, but also for the design of UI, including layout, fonts, colours, user experience, and user interactions.

Unfortunately this process created a series of problems; with little or no design process integrated into the lifecycle of the application, the end result was usually an application that the end user could not use; or the application simply would not make it to market.

The developer’s primary focus is based around software engineering; therefore, a developer is interested predominantly with engineering problems, which cover performance of the application, API calls, patterns for building the layers required in the application, deployment, unit testing and test coverage. Therefore, the problem was not that the developers were not highly skilled, but that they had the wrong skills for the job of designing user interfaces and the user experiences that go with them.

To try to solve the issue, designers were introduced into the process. The introduction of the designer role meant that teams were able to focus on the user requirements, and some teams even started to adopt user-centred design to power the lifecycle of building the application.

Now, although designers brought new ways of thinking and helped change the team focus when building applications, this solution also introduced a number of problems. Designers were given the task of creating the aesthetics of the application; however, the tools that they used were not compatible with the tools the developers were using. For example, some designers produced image-based user interface designs, created in tools like Adobe Illustrator, Photoshop, or other graphics applications.

Developers could not open the design images in the tools they used. Designers were now part of the process, but they were not really integrated due to incompatible tooling.

A consequence of using incompatible tools is that the files could not be easily passed between the two parties, and thus an extra stage of churning out images was introduced, resulting in the designer having to break down the original design and the developer having to reconstruct the design using the pieces. Due to the lack of integration between the two, what was actually happening meant that the designers were creating well-designed UIs, but all this work was carried out up front and without the consultation of the developers, which resulted in clients signing off designs which might not be technically possible in the timeframe or allocated budget. The designers were not always aware of the technical constraints the developers faced.

What we have learnt from the introduction of the designer into the process is that design absolutely has to be an integral part of the lifecycle process and that this has to be achieved from a tooling perspective all the way up to the actual build and implementation stages of the project. I will expand on this later on in the article, once we have explored a new role that has appeared with the introduction of using XAML-based technologies on projects.

The introduction of the designer into the development process has helped solve a number of problems, but it also introduced additional problems that we had not experienced before. However, XAML can act as a catalyst to bring the design and development worlds together. One of the main problems that XAML resolves is that designers are now first-class citizens in the development world. What I mean by this is that they use tools such as Expression Blend that are compatible with the development tools such as Team Foundation Server and Visual Studio, a leap in the right direction allowing designers to manipulate the same code files as the developers. However, the problem of communication of ideas can still be an issue, so the introduction of a role which is being called the integrator is now being added to the mix. Who is the integrator? And what does an integrator do?

The integrator has a design background and understands software engineering problems and has an interest in how these problems are solved. In essence, he or she is happy to write some code.  The integrator can also have a development background, but is also interested in design with a willingness to help solve design problems. The integrator has to have these skills, as one of their roles is to act as a conduit for translating creative design ideas into technical engineering terms, enhancing the communication of ideas and problems between the designer and the developer.

The introduction of the integrator role does add another level of communication into the process that needs to be managed correctly. It is also important to note that the integrator is a role in itself, and therefore, in larger projects, this role would usually be filled by a person. In smaller projects the role can be shared between a designer and developer who may usually be integrators on larger projects. Note that in many organizations, designers have extended their knowledge of development and fulfil both design and integrator roles on projects.

In an attempt to clear up the roles and what happens during the process, we will start a journey of learning how these roles work together in the process to build the Del.icio.us Silverlight application. Before we start this journey. we need to understand what tools each role is using during the process.

Designers use the same tools that they have always used: graphics applications like Adobe Illustrator, Adobe Photoshop, or Microsoft Visio to create their designs. They may also be using sketches to visually work out some of their ideas for the application.

For the designer, the only real workflow change, if any, is that the assets they are producing should always be vectors, except under certain circumstances where the assets can be images. Depending on your environment, I would always suggest that these assets be stored in a Source Control Management tool so everyone has access to the current state of the application.

The integrator will be using Blend for the majority of the work, but should also have installed the designer’s tools of choice and Visual Studio.

The developer will primarily be using Visual Studio, but should also have Blend installed. When the developer is building lookless controls for the integrator to template and style, it’s important that these are rendered correctly when opened in Blend, because controls created need to have a high level of Blendability. If the integrator is unable to view the controls and assets at design time, then we have a serious issue. Blend is also the tool of choice for creating UI elements, navigating templates and styles when compared to Visual Studio.

To reinforce how the process can work, let’s start our journey of building the Del.icio.us application. The designer has already done the scamp, and as a group we all get together to talk through the design and how we are going to make a start building the application.

The scamp (preliminary design) above illustrates each particular part of the application design and experience. With more complex applications, a storyboard approach works very well, and provides a good communication vehicle to work out problems or offer suggestions about enhancements to the current design. It’s invaluable for the team members to have a visual representation that they can see and interact with as a group.

Interactions are another talking point that the designer will want to cover, with regard to how the application will react when the user performs certain operations, or how the application should respond when data changes in the application. To provide a better understanding of how each role views the design, here are three illustrations of the above scamp which concentrate on particular areas of interest to each of the roles when carving up the UI into tasks.

The designer’s tasks when carving up the UI include: custom background, styles for the custom buttons that may include gradients, creation and importing of vector graphics, animations, and custom fonts. (See the blue illustration below.)

The Integrator is focused on templates for presenting the data in the UI; which controls are best suited to manipulating the layout based on the designer’s requirements; an awareness of controls that are standard or included in the Silverlight control toolkit; and animation triggers that need to be wired up. (See the green illustration below.)

The developer has a completely different view when carving up the UI, as he or she is primarily focused on the architecture of the UI; the developer is also thinking about the best ways to get the right data from the data layer and service layer into the UI. LINQ, which is supported in Silverlight, will also be taken into consideration for projecting and manipulating data; custom controls are also a developer task, as the developer will be required to build controls when the standard controls fall short; and finally event handling of controls. (See the red illustration below.)

During this upfront session, all team members communicate their views of the world as seen from their respective roles. Even though they see the world differently, each role is dependent on the others. For example, in order for the designer to style the custom button templates, the integrator needs to have created the custom templates; and to apply these custom styles and templates, the developer needs to bind data to the controls. This not only applies to data but also relates to animations and event handling.

Now that all roles within the team have communicated what their tasks are and how they are related, it’s time to start building the application. At this stage, I should also point out that although there are three roles involved in the process, they are not all working at the same rate all of the time in the life cycle. At certain times the developer and integrator are actually doing 80% of the effort while the designer will be doing 20%; at other times the designer may well be doing 60% while the developer and the integrator will be doing 40%. So the percentage of effort for each role is very much blended at different rates depending on the different stages of the project. The process itself is an iterative one and attempts to complete end-to-end journeys that the user wants to experience, rather than trying to build highly polished controls that are incompatible with each other. The simple rule here is to provide an experience and UI design and then enhance this experience over time.

Usually the developer is responsible for starting the build and development process at the beginning of the project, and for me this seems the most sensible option. Once the project structure has been created, the rest of the team can also start to contribute. The designer can start to export his or her assets to XAML or images where required. The integrator can start to add controls and control templates that the team wants to use. The developer can start to put in the mechanisms to fetch the data from the services and the underlying layers that will support a rich interactive UI.

The designer’s next stage will be to start to style and add brush resources to the application in order to style up the templates that have been added by the integrator. Once the developer has the underlying layers ready, he or she can start to data-bind the UI controls. Once the data is coming up to the interface, the Integrator can start to add animations that need to be triggered when the data changes.

We have covered a number of different concepts in this article, many of which I appreciate are new, and therefore I would suggest concentrating on the carving up the UI part of the article, as I have found this to be the most useful on XAML-based projects. Good communication is the key between the different roles; and if you can succeed in doing this effectively, it will allow you and your team to overcome the majority of problems. In the next article we will apply the concepts outlined above to building the Del.icio.us client in Silverlight. If you would like any further information or have any questions about this article, please email Richard.Griffin@conchango.com and I will respond accordingly.