The design phase


Leading on from my previous post about the lessons that development teams can learn from game studios, I am going to start to explain the process that I implement in teams of different sizes in a hope that you yourself can start to create your own processes around it.

I am not going to try and give a clear definition of any one job role, because each company (and indeed each individual) has their own methods of doing “their job”, so I am going to point out what parts specific roles have in the process and you can take what you like if it is relevant to your position.

This article is looking at the roles of the Interactive Designer (ID) and Graphic Design (GD) in the process, working with the XAML Architect (XA) (a.k.a. the Integrator).

The process is represented by the following (very generalised) 4 phases to creating an entire application.

1. The design phase 2. The design implementation and prototyping phase 3. The object model planning phase 4. The business logic implementation phase Of course there are several other areas of the application process that also need to be designed and implemented such as the distribution mechanism etc, but here we are concentrating on the bulk of the designer/developer collaboration pieces to end up with an application. Testing is also a given and should not be changed if current methods are agreed and perform as desired.

The process begins well away from Expression Blend and indeed Visual Studio, with the ID working through the design brief to understand what the overall use cases are with the application. The ID also begins to form a picture if you will, of what the experience should entail for the end user and how the product should be projected.

It’s not unusual for the ID and XA to discuss in detail some of the finer points of the application, maybe some specific custom control requirements leading into any specific business requirements such as security and workflow sequence, if only to understand and verify that the conceptual flow of the application will work.

This next step is a novice step added to the process which I will describe after why it would be better to not have to do this, but for most designers, it is currently the only methods available because of experience (or lack thereof)with XAML and WPF in general.

The ID works with the GD (or graphic design teams in some cases) to piece together a storyboard of screens that give an overall visual perception of the end product, as well it doubles as a roadmap for the generalised UI design implementation. If the GD (and hopefully the ID) both work in a product such as Adobe Illustrator or Expression Design, then specific areas of the artwork created can be reused within the application. I say specific areas because it is rarely viable to take an entire UI designed in a XAML exporting application. The specific areas are artefacts such as iconography or button designs that have intricate detail and would take too long to reproduce in Blend.

Along with the screen illustrations that are signed off by the stake holders, the GD should directly indicate on several duplicated illustrations, the dimensions of the individual elements, font families, sizes and weights as well as all colour requirements in ARGB format as shown in the image series below.


So you are probably thinking right now that this particular piece of the process requires a lot of time, and until people are used to it, yes it is time consuming, but… It is a lot less work to go to the effort of adding this detail than it is to write a 200 page requirements document that attempts to explain it in words rather then pictures.

Some of you may also be having a grumble right now, because you were sold on this concept of “rapid prototyping” with Expression Blend from Microsoft, which is fantastic and exactly the process you would rather be taking to really speed up this entire design phase, except for one little problem: if your designers are not comfortable with Blend, then you are not going to get a heavily designed prototype. So part of your internal training and time allocation should go to getting designers more and more comfortable within the Blend environment overtime.

So there you have it, the design process which isn’t really that complicated, but essential to getting the project off to the right start where all members understand what you are trying to build as well as vitally having a signed off design brief with examples of what the end product should look like.

The next part of the process, which will be the subject of the next post is the design implementation and prototyping phase.

ITWorld DealPost: The best in tech deals and discounts.