This is a blog post I have been meaning to write for sometime now and since I am sitting out on the balcony enjoying the winter sun now seems like as good a time as any.

I am often asked how do I approach a new project. This is not a simple question and one that many, many people struggle with. I don’t think there is 1 simple answer but we do have our preferred approach and that is to separate design (UI) from technology right from the start.

When I say that I really mean separate them. Break your project in to 2 phases and split them across 2 companies.

Step 1 – Get your user interface design done by a professional design company with a reputation for good UI.

Step 2 – When you are happy with the design pass that design to a different company. A development company that specialises in technology. This is what BondiGeek does.

Now I can already see a few brows’ being raised so bear with me on this for a moment. I have valid reasons for saying this and they almost always stem from budgets being blown and/or poor implementation. Neither of which you, the customer, want.

Designers are not Developers

Ok so why the design first? Simple, we are visual by nature and they didn’t coin the phrase “a picture is worth a thousand words” just for a laugh.

So let me clarify what I mean by design: Design is what your end product will look like. It has your desired colour scheme, fonts, layout and all the elements that will appear on the screens/web pages of your final product. It will usually be produced as a series of images that a graphic designer has created using a product such as Photoshop.

When you have something tangible to look at it starts to open up a conversation and people start to really engage with what is being developed. When we can visualise what our end product will look like we see things that we might not have considered and we start to question things. Things that may have appeared important or critical can often fade in to the background in the context of the entire design.

Another by-product of getting our design right first is that it actually starts to document our product. As we lay out forms we start to see clearly the key pieces of information that our application needs to collect or display.

None of this needs to be of concern to a technical team at this stage. Sure it might affect how the final product will be delivered technically or how much it will cost to code it up but, during the design phase, we are only concerned with the look and feel.

At the end of the day you should expect whatever design house you employ to supply the following:

  • 1 or more .psd files
  • Font specifications
  • Colour Pallete
  • Screen wireframes with measurements

So how important is the design phase? Well it’s very important but just how important it is depends on your budget. You should decide how much you are prepared to spend on design alone and try and stick to that.

And that is the reason why I say you should separate your design from your implementation and do it with 2 separate companies. I can’t tell you the number of times I have seen a project handed to a so called “1-Stop-Shop” that claims to be able to do both design and development. 9/10 times these companies are run by graphic designers and the tendency is to spend all the time in the world on a flashy design.

This eats up your budget. You should be concerned how much of your budget is being spent on making your project look pretty and how much is being spent on making it work.

To then try and keep the project within budget it is farmed out to the cheapest developers. Cheap and Experienced do not go hand in hand. Trust me, when you look under the hood of a project that has been delivered in this manner it’s not pretty. It will be buggy. It will be hard to maintain. It will more than likely cost you your initial budget again to get it fixed.

Let’s take the analogy of building a house shall we as it’s a simple one. You employ an architect to create your blueprints. You spend time with the architect discussing the design and when everyone is happy that design is passed across to a builder. Software is no different and you should not treat it any differently.

Now don’t get me wrong, I have the utmost respect for good designers and consider the UI Design an extremely important part of any project. But, it must be looked at in the context of the entire project. Don’t hand a group of designers a blank cheque when it comes to your budget. Design is only part of what needs to be delivered and it should be budgeted for accordingly dependent on how important the design is to you. If you are not specific then designers will spend all the time in the world coming up with the most ground breaking design for you and you may find you end up with some amazing blueprints but nothing left in the coffers to pay your builders.

Developers are not Plumbers

Ok so now that I have told you that developers are like builders let me take a step back from that statement which was used for illustrative purposes.

Developers are creative, they are not plumbers. There is no “1 size fits all”

Technology changes constantly and good developers are learning all the time. They are skilled craftsmen (or women). The landscape is constantly evolving, new devices are emerging, new versions of browsers, new and better (not always) ways of achieving the same end result are appearing all the time.

Sure there are pieces of re-useable code and various frameworks and an experienced developer will know which are the most appropriate to use and how best to combine them but that is only part of the story.

So what should you expect from your development team?

A development company should be able to take the design that you supply them, usually in the form of .psd files that you have paid a designer to produce, and create a clear separation between the UI code and the backend code. *What does that mean? *They should be able to split the development in to 2 areas, the front end coding and the backend coding.

Front End Development

  • The front end developer will take the elements of the design and create the HTML, CSS, javascript and combine this with the image elements that will be sourced from the .psd files, font spec, colour palette and wireframes.
  • They will write the necessary scripts to manipulate the html on the client browser to react to events raised by the end user.
  • They will communicate with the backend code to update and display data.

Back End Development

  • The backend development team will create all the plumbing (bad choice of words) and data storage that your project requires.
  • They will expose, in a secure manner, the necessary interface that the front end developer will need to communicate with.
  • They will code any project specific business logic that is required. This should not be on the front end.

You should expect your development company to be able to execute both of these roles. There are excellent front–end developers and there are excellent back-end developers but you don’t want just one of these, you want both. Depending on the complexity of your project and the design there may be more focus on one of these than the other but your development company should (almost always) be experienced in both.

One of the immediate benefits of delivering your project in this way is that the separation of design and development means that a clear separation of front and back end development is easier to achieve. The more you can separate front and back end the better position you will be in at a later date to refresh your design without having to worry about your back-end breaking. You can skin your sitemuch easier.

Now, as I would not hand the development work to a designer I would also not hand the design work to a developer. There is the odd exception but that is a rare beast indeed. Developers think of things in a black and white way and hence they usually come up with a somewhat clumsy design when they try and design a UI. This is another reason why the clear separation method works best in our opinion, you get a much better product this way.

In addition when the design work is already done and signed off by the customer the developers can start to break down the design in to components; image sprites, blocks of html, templates, headers, footers etc. The more that a project can be componentised and patterns identified the more testable and reliable the code will be. If the design is just made up as the project progresses code becomes fragmented, sloppy and hard to maintain.

There is another reason that you should consider this separation. Designers are not concerned with issues such as hosting, ssl, databases, eCommerce requirements, dns configuration etc. These are all things that a project may or may not need and they should be considered at the start of any development project as they may affect the way in which your project is developed.

  • Do you want to host it in the cloud or on premise? This is a development issue not design.
  • Do you need to take secure payments and how will this be done? This is a development issue not design.
  • Will you need to integrate with any 3rd parties and how will this be done? This is a development issue not design.

Don’t trust a designer with stuff like this. It is not in their skillset and often needs to be considered up front before writing a line of code and processes need to be put in place well in advance. These things take time so plan for them well in advance.

We had a project delay recently not due to any technical reason but because of red tape with a bank.

Final Thoughts

There is a lot more that could be said on this subject but I hope we have impressed on you the importance of separating these two phases of your project.

At the end of the day you will save yourself a lot of heartache and money if you take this approach to a project. Don’t let yourself be lured in to handing over your entire budget to a group of groovy designers. What they deliver on the surface may look flash but the UI is only the tip of the iceberg when it comes to a website or any other type of development project.

Remember, it was the bit of the iceberg that they didn’t see that sank the Titanic so budget for your development team accordingly or risk going down with the ship.