Lessons Learnt From My First Time Translating Design To Code
Sometime last year, I received an interesting email from a designer who wanted to work at Codaye. At then, Codaye was just Joshua Azemoh and I, and we were not looking to hire anyone else. But this guy’s portfolio looked so good, it made me reconsider. I talked it over with Josh, and he liked the idea of having someone make design decisions for us, so I decided to speak more with this prospect.
I replied the email saying I liked his work and we discussed a little so I could get to know more about his methods and why he wanted to work with us. Eventually, I gave him a test which was to create a concept redesign for the Codaye website and he was happy to go with that.
Here is what the site looked like as of then.
After a few days (and a little later than the deadline 😒), this designer sent a mockup that really impressed me.
This, ladies and gentlemen, is how I met Olusesan Peter. Needless to say, he got the job.
Here is what he presented.
I know there are flaws to this design (even Sesan himself has grown way past it and is not keen on the design anymore) but I love it so I implemented it, with my improvements.
Because this is the first time I am implementing a design made by someone else, I learnt a lot along the way.
Here we go:
My Process
My process of translating a visual mockup to code was very silly at first. What I was doing was looking at the mockup and then estimating what padding or font-size, etc. to use in my code for the end result to look like the mockup. From my experience working with other developers and designers, it seems I am not alone in this unfortunate practice.
But ideally, the design should provide exact estimates. The visual design should model real browser dimensions so that all the developer needs to do is implement instead of thinking of if what he has coded is as exact as the mockup. Meaning if the font-size on the PSD is 20px, it should be the same in your CSS file, and so on.
A tool I use called Zeplin helps translate the design PSD or Sketch file, providing you with the right dimensions. It even generates the CSS for the website or the XML if you are designing an Android app.
My Challenges
Because there was no communication between I and Sesan during the design process and for most part, when I was developing, a few things did not work well.
My problems were with fonts.
To start with, Sesan used a beautiful font called Brandon Grotesque in his mockup.
Turns out it is a premium font, and since it does not make business sense to spend $249 on a font for a small Nigerian business website, I started searching for alternatives. Unfortunately, my search yielded no alternatives that looked close enough to the font — Brandon Grotesque is that unique. I eventually settled for Montserrat Alternates as the main font for my body.
It should be made clear to the designer which resources will be purchased, if any will. If there is no budget for fonts, it should be decided whether the ones used should be Google Fonts, fonts hosted on another platform or self hosted fonts.
In Sesan’s mockup, the title of the home page section was a fancy combination of two different fonts —Montserrat and Playfair Display. I really liked the concept on the mockup, but when I imported those fonts and used, the results were not as pretty.
I decided using just the Montserrat was better, which was I opted for on the website. Using one font instead of combining the two gave consistent letter-spacing without having to tweak.
Consider browser rendering when using design elements. Be creative but factor in limitations (browser compatibility, for example).
And speaking of compatibility, some things are quite impossible or at best, not worth the trouble they give.
Take a look at the section title on this part of the mockup.
To put the section title “Works” behind the laptop, I have two options from the top of my mind. Either make the word “Works” a background-image, or write it in text and give it a lower z-index than the laptop image.
In my opinion, it is unnecessary and counterproductive. As a background-image, the word will not be accessible to screen readers or browsers that have images turned off. If I go with the z-index option, I will need to do some positioning acrobatics to make the text stay at just the right position under the laptop image. Unnecessary. When you combine this with the fact that all this wahala is just to hide a title that should stand out, you will likely do like me and go the boring route and place it in plain sight.
At the end, here is what my translated version looked like, with multiple modifications.
The website now lives at new.codaye.com where it is going through a few tests and minor improvements till I move it to production.
The full code is available on Github.
Takeaways
- My greatest takeaway from working on this mini project is that communication is essential at all stages of the work. I literally gave Sesan no parameters and we didn’t get the chance to properly revisit the project together again. Next projects, I will make sure there is a lot of communication and agreeing together on.
- Working with a design really reduces the engineer’s work. I know this is a really small scale project but it made my work easier by far. I even preferred working this way than using a HTML template and editing on the fly. I can imagine how much easier it will be on large scale projects.
- Best way to learn is by doing — put yourself out there and work on something practical.
That’s all from me. If you learnt from this, please 👏🏿.
