get in touch

** I am unavailable for freelance work until January 2014 **

If you'd like  to get in touch about a freelance project or just to say hi, please send me a message using the form or via twitter at @ivonnekn.

~ Ivonne

 

 

 


Milton

Designer and illustrator specializing in brand identity design, web design and UI/UX design, based in Toronto via Milton.

Journal

Respect and consideration

Ivonne Karamoy

Our role as a designer is to use our creativity for a purpose, to transform experiences into one of function and beauty. We think and strategize about how people use our products and interact with experiences on the web. We make things beautiful and engaging while enabling users to focus on the task at hand. For our designs to function well and serve the needs of a business/person/user, it helps to understand the technology that underlie it.

Understanding the intricacies of the web, how it runs and how things are built allow us to understand what is and isn't possible and how to design the best experience given what we have. Designers and developers collaborate more now than ever before for this reason. We work together so we can rely on each other's expertise to inform our work and to better it.

There's a question as to whether a designer should learn how to code. I think it's not merely a matter of learning to code in order to code our designs but to understand the underlying technology that allows our designs to function. An ideal project may be one that begins from scratch, with a code base that is built based on the initial designs and iterated upon. But for designs that are revisited or complex products that evolve, it's not always possible to rewrite the code base. In product development, you build on the code that's already there and sometimes interactions are not possible without having to dedicate many resources (time, development and money) to overhaul it.

It can be a frustrating situation for both a designer and developer to be in. We want to design a certain experience but the back-end may need to be rewritten to do it and there's not enough time or budget to do it in. A designer who understands the underlying technology can appreciate the complexity that the developers are dealing with. That doesn't mean that the designs are impossible. It simply means that we need to weigh the design and development efforts for the project, consider alternatives, imagine scenarios - in short, have a dialogue and plan.

As a designer with a strong technology and development background, I'm able to have in-depth discussions with my developers on implementation issues. I trust in their expertise but I am able to understand their decisions and question them. I'm also able to question my design decisions and whether it's worth a code overhaul, for example. I can empathize with their experience building a design and ensure that I give them all the assets they need to implement my designs in a way that's easiest for them - that means slicing images and naming them properly, providing font files, labelling my psd files properly, providing ready made css styles, etc. 

This empathy shouldn't be one-sided either. Developers may not need to learn how to design or understand typography or grid systems to the point that designers do, but it's important that they respect the principles of design and rely on designers to make informed decisions that solve the needs of the project. It's extremely easy to pick on a design, but instead of criticizing it, critique it. Take some time to understand the design decisions and how the designer has come to it. Again, have a dialogue. There was considerable time and effort put into our designs and trust me, we've thought of the alternatives and came to our decisions thoughtfully. We're all approaching the same problem and trying to solve it. If there's some really important technical issues that our designs might introduce, then let's hear it out and work through them together. And when it comes to implementing the designs, respect the details - the typography, the spacing, the grid system. Think of them as your curly brackets, your comments, your file structure. We are as particular about them as you are with your code.

At the end of the day, it's about mutual respect and dialogue. I've worked within a team where we have mutual respect for each others craft and can battle it out on design and implementation details. And the result is always a better, more cohesive product.

Everyone on the team should be respectful of each other and their work. Be considerate of each other. That means sales people who understand the advantages and limitations of the product or service that the team builds or provides. That means managers who respects everyone's time and ability and schedules enough time to execute the work to the best of their abilities. It's not always easy especially if money trumps everything else. But the best work environments are the one's that respect the project, the client, the different roles on the team and provide resources for everyone to work to the best of their abilities. There's nothing worse than being disrespected for your time, effort, ability and/or talents.