On Integrating 3rd Party Graphic Designer with Internal Software Development Cycle

Outsourcing graphic design to a third-party organisation is a very common situation. It doesn’t matter if the company is a pure software development company or a larger company with its in-house IT department, I think this decision make sense. Sometimes we do need outside the box opinion and one would trust that professional design firms have more experience in creating great user experience for the customers.

The Problems…

Like always though, there are challenges when bringing in 3rd party companies into the internal software development life cycle. The issues can range from differences in opinions about creative decisions, breakdown in communications resulting in project stretch, slow decision-making process, misunderstanding of requirement specifications and many others. Problems like these cost a lot of money, especially when the project becomes late. In addition, this can also put a lot of stress on the development team members which leads to poor ownership level of the product in development.

In other words, the developers would think that the software/project that they are working on, does not belong to them, instead it is something that is being forced upon them by the 3rd party designers; even though I think that this is mostly not the case. On the other hand, the creative designers might think of the best design and might not understand whenever the development team told them that something is expensive to develop (I’m not going to say impossible or difficult because nothing really is when you have the means and funding).

This article is a reflection and suggestions of how we can integrate 3rd party graphic designers with an internal software development team. Although most of these points will seem like common sense, it will be good to think through them when we have a chance.

Synchronize your Requirements

Every project must have business requirements to begin with. These requirements must be distributed to both the 3rd party designer and the in-house development team. Even though the 3rd party is an outside entity they should be briefed consistently so that they can come up with appropriate suggestions.

The worst thing that can happen is when the development team and the 3rd party designers all having different versions of requirements. This can cause confusions and unnecessary debates between all the parties. The way to prevent such things from happening is by using a generic mailing list or a central document repository.

Examples of these systems are:

• Knowledge Tree
• Open Atrium
• Microsoft Exchange
• and many more.

By using these tools, you can be assured that all the parties involved in the project have the same version of the requirements documents.

Create Storyboards

A picture is worth a thousand words. It’s of course great to nail down the functional and business requirements perfectly. However the problem with requirements is that they are mostly words and many people including myself can and will miss a word or two within the requirement. The misunderstandings might seem trivial at times, however over time they will definitely cause problems. Imagine going through 300 pages of functional requirements then having to read all of them again when the functional requirements are updated. There are bound to be misunderstandings these way.

I think it would be better to have visual storyboards that both developers and the third party designer can refer.

Creating story-boards is a great way to encourage collaborations between the 3rd party designers and the developers. This way, both party will have a sense of ownership over the products that they are designing and developing.

The tools to create storyboards does not have to be fancy, it just have to be something that can be shared easily between parties. Online diagramming tools such as LucidChart or desktop software such as Visio or DIA can be easily used to create these storyboards and flowcharts. Of course when using desktop software you’ll have to keep the saved files shared between all parties.

Include Development Team in Creative Decisions

Developers tend to think logically and that everything has a state, while creative designers think more of the aesthetic. In order to build dynamic applications (web or native) that looks great and consistent in all the state, we really need to make sure that both 3rd party designers and developers talk and listen to each others. I emphasized listen because without listening nothing can be achieved.

Also, I like to think that developers are artists. They can sometime take immense pride on what they are building, therefore it is important to include the development team in the creative decisions to increase their sense of ownership. Of course it doesn’t mean getting every single developers’ opinion when creating the design, it can be chaotic with too many chefs in the house and a lot of developers may not want to get involved with the design.

It’s more informing the development team of the overall objectives of certain features to be developed. Then after that, listening to all of their suggestions (if any) in regards to the creative decisions. You never know when one great looking design will break on certain states of the application. For example: a welcome page of a website might look great on a 1024×786 screen, but what happen when it’s opened on a mobile device? Perhaps then we think of responsive design, but there might be other technical limitations such as the screen size of the device, what element to remove or add to the mobile version, etc.

So make sure both development team and 3rd party designers work and listen to each others.

Keep the Communications Channel Open … Keep Giving Updates

As I mentioned previously, both parties must listen to each others. In order to do this, we need to keep the communications channel open. When any of the parties are unsure, have new suggestions or hitting a new milestone; we need to keep everyone informed. This is very simple to do, in this day and age there are countless technologies that will allow us to collaborate.

Some tools that I can suggest are:

• E-mail (a bit slow at times)
• Conference call
• Skype group chat
• Internal social network service such as Socialcast or Yammer
• Other group chatting mediums.

Version Control for the Assets

As the development team and designers gone deeper into the development process, there are bound to be many illustrations, mockups and prototypes being generated. One thing that baffles me all the time is that there are no version control for most of these assets. Perhaps because not many people are comfortable with the idea of committing and checking out assets. Version control though, as tedious as it might appear, can prevent development team from developing a totally off the track solution based on old assets. Reverting these work and re-implementing the newer assets can be time consuming hence expensive.

The tools that I can suggest for this kind of version controls are:

1. Central document repositories similar to what I suggest for keeping track of the requirements
2. Cloud sharing services such as Dropbox, Box.net, SkyDrive, etc. Of course you’ll have to store the assets in dated folders.
3. Shared dated folder setup if you have your own server via Samba
4. FTP server with dated folders.
5. It’s also possible to use version control software such as Mercurial or Git for assets. Larger sized assets might be a problem though as the file comparison would take longer.

Acknowledge Each Others Strengths

Lastly, I cannot stress this enough that both the development team and 3rd party designers must acknowledge each others strengths. We are all professionals and trained with different skill sets. Therefore any suggestions made must have a reason and logic behind it. Never dismiss each others ideas as that idea might be the unexpected key to success.

Conclusion

I know this article today is slightly different to my otherwise more technically oriented post, however I feel that this is one of the topics that we all have to think about. In conclusion, in order to gain synergy between 3rd party designers and in-house development team, we all must keep in mind the following suggestions. Always keep the requirement synchronized between each parties to avoid confusion.

Then include the development team in creative decisions as well as keeping the communication channels open between all the parties involved in a project. Furthermore, when going further in the development phase, remember to always maintain the latest version of the assets. Lastly, never forget to acknowledge each others strengths.

Categorised in: Business Process, Web Design