So, I’m a web designer who codes. And no, I’m not going to get deep into the discussion of ‘should designers code?’. Fact is, I do code. Why? In part, because my job requires it, but mainly because I enjoy it and I do believe it makes me better equipped in my line of work.
Sure it opened doors, but above all it made me see how to get the most out of what I’m designing for and its limitations. Soon enough I was designing and coding a good chunk of my layouts in the projects, at least concerning front-end.
Was the designer in me gone?
At a given point I was enjoying more coding than designing. Was I becoming more of a developer, morphing into this other species? What was missing in the design phase? Took me a while to realise. Process!
I was designing in a monolithic manner more concerned with UI than anything else. At that moment, working with HTML and CSS, seeing the project come alive was more thrilling. And by comparison less painful when it came to the corrections/requests for changes. You change a SCSS variable here or a HTML class over there and you’re good to go. On top of that, having a preprocessing with browser sync operation going on was very satisfying. The inner designer was thrilled to see the UI becoming ‘alive’.
It was then I realised that I had to get a way of shifting my design process to be more similar to coding. And in good time I did. I got involved in a project of a web app that had massive demands in terms of UX and UI. There were quite a few people working on it at the same time, getting access to the same files and on top of that, sometimes, I was designing via screen share.
Until this point, I did my designs in Adobe Illustrator(AI), and it just wasn’t serving the needs I had in hands. Sure I had some libraries and was working with smart symbols, but the constant shift in the direction of the project was taking its toll. My files and structure were just too stiff.
Searching for a new solution
I had to take into account the specifics of the web app - a ton of components, ranging from simple buttons to actions groups, tables, modals, messages - and a whole variety of layouts made of simple pages, cards, rows, among other content blocks. And of course their 'atoms' and 'particles' - icons, fonts, colours and text styles.
Looking through the available options, I turned my attention to Sketch. I had explored it a bit in the past, but in the same monolithic way I did with AI. This time really dug into it. Took the time to set up the files in the most dynamic way I could. My take on it was making all assets miming as much as possible an atomic design system. A component approach with shared libraries using symbols extensively.
The process itself
I started by sorting out the basic graphic elements to compose the main library serving the whole design system. The first step was to establish the layer styles. Then, collect all the colours and text styles. Having done those, I gathered all the icons, and to each one, a symbol was created. In no time I had a base of colours, text styles and icons to serve a whole project with the sweet benefit of updating across all instances at any given point in time.
In the UX process, while the type of components was being defined, I was designing them the way I would code them. All the component parts should be symbols to allow overriding and updating. The simplest button was set up with all the states, colours and icons as dynamic symbols.
Another great thing Sketch allowed was the override of texts and images in the reuse of the symbols. This was really valuable to provide the mockups with a certain realism beyond ‘lorem ipsum’ and see how they were behaving in a variety of scenarios. This was critical. Before the development team start the backend work, the mockups had to be validated by the marketing team and other stakeholders, who, for better or for worse, needed to see the layouts as finished as possible, meaning, with real data applied on them. Tedious, but a requirement nonetheless. But now I wasn’t scared of changes, the whole structure was ready for the updates and changes.
Care to elaborate?
For instance, consider a form. All inputs were composed of components filled with several symbols organised in a responsive way. Exploring the elements anchoring, how will they pin to the edges of the parent element, whether is their size fixed or not, all the ways I could override an action icon, having or not a label on the input, etc.
But it wasn’t just the native options of Sketch saving me. There were also some awesome third-party plugins helping out. Got to become best friends with Anima Toolkit. This great plugin was invaluable with its Padding options and with Stacks, which literally made layout composing as web-like as it gets.
How so? Take a structure of twenty rows with 20px between them. Remove the third, the eleventh and fourteenth. A bit of rearranging to do, right?
Let’s complicate it a bit more, shall we? Say now you have to swap those rows order and make the margins 40px. It is starting to get a bit annoying at this point, not to mention time-consuming, especially if you’re designing via screen share.
If you build that structure with Anima Stacks it will automatically adjust the content for you. Even if you have to change the width and/or height of an element, the plugin will even accommodate the surrounding elements. How close can we get to Flexbox in a vector graphics editor?
I only got the full spectrum of what I was setting up because I was used to working with a SCSS organisation respecting a component-based approach, in which the styles, variables and mixins are set up independently.
In fact, another great plus is the ability to right click an element in Sketch, and get its CSS code, or exporting for Zeplin or InVision getting HTML/CSS information. This drastically improved the transition from design to code.
All in all, what improved?
This project pushed the bar on many levels. On one side, the UX development was quite complex and intense. Sketch ease of use helped quite a bit here, contributing to a more intuitive flow from wireframe to mockup.
On the other hand, there was a lot to cover in terms of UI due to the extensive nature of the app. Just as the development team has to overview the (vast) landscape of the app codebase, the same had to be said about the design team files. The source files are organised properly, but above all, they are built upon the same common Sketch libraries.
What is the result? Consistency and the option to update all the structure if needed with minimum effort. You just update the main library, when you open any other file it prompts a warning message noting which of the components were updated.
To design a good User Interface means all the colour schemes, all the text styles, buttons, icons, shapes, whatever visual elements compose the site or app, are done to answer the product needs in a consistent way. And in my view, organising a project this way should definitely be part of the design process. With tools like Sketch and its invaluable plugins, you will be able to set your design project having the assets dynamically fed from master libraries just like a living style guide.
So should a web designer code? It sure helped me to gain further insight into my projects and better interact with development departments. And on top of that, it helped me getting better work habits and methodologies into my design procedure.
(Edit 2019-09-11) Extra reading
It's nice to know that this kind of approach can be useful to other designers out there. If you enjoyed reading about my experience, there's a nice article by Lucijan Blagonic, titled ´Approaching the Website Design Process from the Browser´, that you might also want to check out.