Registered users

If you're new, then please register here or if you've forgotten your password then enter your email above and click on the button

Articles

Designer/Developer workflow

Designers and developers are often specialists in their own right. When the two are commissioned to work together on a project, it is interesting to consider the issues that may arise and how the two skills may combine to create an end website/application.

Firstly, who makes the first move on a project? This is obviously determined by the party who has commissioned each role and at what point the individuals have been brought in on the project. There are four common scenarios:

  1. A developer commissions a designer to embellish a developed application.
  2. An end client commissions a designer to embellish a site/application they have developed with the developer.
  3. A designer creates a static design to which a developer is commissioned to add functionality.
  4. An end client commissions the developer and designer to work on a site simultaneously.

For the first scenario, a developer may have created a slick application that offers the user considerable functionality but is aware the application could be improved in terms of appearance and usability. A designer might choose to tackle each screen/page in turn: create branding, buttons, icons and graphics to enhance the overall experience. The designer may do this by submitting static versions of the elements for the developer for he or she to implement. Depending on the knowledge and experience of the designer, plus the physical access to the project, it might be possible for the designer to style the elements in situ, so to speak, and actually implement the changes themselves. At some point, however, it is likely that a designer might suggest a change that impacts on the functionality of the application or the way in which it has been written. Under these circumstances if may be necessary to weigh up the developmental costs and deadline implications of implementing such changes to assess if it is realistically achievable.

It seems fair to say that the benefits of scenario one can be superficial. Design intervention (not divine!) is most likely an embellishment to a well-established project, pretty much set in its functionality and flow. The design input will add a polish to the surface but will not effect the fundamental structure.

For scenario two, the workflow would work much the same as for one, yet there is a further issue that could affect the project�s progress. It is possible that the developer and designer are unfamiliar with each other�s work and may not ever meet. If a client has sourced a designer independently of the developer with which he or she works, there could be a mismatch of expectations regarding who�s role is who�s and of what exactly is to be delivered by each party. A designer may deliver a static image to show how a page might look whereas the developer might be anticipating an HTML page with individual graphics. In this scenario it is essential that the client manages all expectations and establishes the deliverables for each party.

In some circumstances, a client might request a degree of functionality that is beyond the realms of the designer�s skillset. The designer may feel able to assist with the application of this functionality by providing static screens to represent how the site/application will flow, but is unable to develop the technology necessary to perform the task. A developer may then be commissioned to complete the work. It may be that the developer would work with the static pages the designer has created, were they suitable, and build the code around the styled version. Alternatively, the developer might generate the functionally application and then hand it back to the designer to style. If the developer recognises a slicker approach to any element, then it may be necessary to adjust the design. Again, a set of pre-defined requirements for all parties are crucial.

Perhaps the ideal scenario in terms of developing a successful application, would be to involve the designer and developer from the outset, simultaneously. Preferably a team would form who have worked together previously and are aware of each other�s work practices. This approach means that usability and functionality can be discussed in equal terms from the outset and decisions can be made on the role of each party so that a clearly defined goal can be worked towards and a successful solution achieved.

Article by clear breeze | design

read more on web development >>