Last week, I finally received my Nanodegree in Front End Development after 6 months of hard commitment. When I first decided to embark upon this journey, my goals were pretty personal. I wanted to do side projects and build hi-fidelity prototypes on my own. I was especially inspired by the works of Jongmin Kim, current Senior UX Enginner at Google (His work is pretty awesome! You can check it out here).
However, coming out of this course, I realized that I had not only gained the ability to publish my own ideas, but that the skills I had gained were helping me bring more value to my everyday job as an interaction designer. Here is some firsthand experience on how I translated my newfound skills to my workplace.
The Obvious Benefit, Communication
If you’ve ever searched for the question “Do designers need to know how to code?”, 90% of the responses will say that understanding the basics will make it easier to communicate with developers. No surprise here!
This came into use when I first started writing descriptions for wireframes. Now that I knew that lists couldn’t just be magically sorted in alphabetical order without being told to do so, I was able to look at my designs from a programming standpoint, and fill in most loopholes in my descriptions so the developer did not have to constantly message me asking me how to handle every single situation.
Knowing how to code also helps with understanding technical jargon. I work for one of the Tech Giants, and because it is a software based company words like ‘tokens’ and ‘parsing’ are commonly brought up in everyday meetings. Because the employees are very specialized in tech, sometimes even the designers are expected to understand most words without stopping to question. As a junior designer, you can imagine the number of times I had to secretly look up words so I could stay on track.
However, after learning to code and having actually used most of these technologies firsthand, I can definitely say that I feel much more comfortable communicating during these meetings. I no longer have to ask what it means when the developer says they need time to ‘refactor’ the code, or ‘deploy’ the app.
Expanding Design Possibilities
While working throughout the course, I realized that the world of programming was much more user-centered than it appeared to be. For example, I had no idea how much work developers put into optimizing pages for a faster load, or how much time it took to optimize my designs so it would look the same across all different kinds of browsers.
I also did not realize that underneath there were all sorts of usability-enhancing technologies that I could utilize in my designs. One great example would be asking to implement a Service Worker.
Basically what a service worker does is it caches information you have already seen on the web so it is also accessible on an offline environment. For example, if you are creating a travel app you could cache the map and travel route data so that people could still access them even if they lost internet connection. Another common pattern is the use of placeholders, like Facebook uses below. In this example, the browser caches the global and local navigation bars, so that users feel like the content has loaded faster.
If the developer you’re working with has already implemented these features for you, great! However, sometimes these may be important design decisions and you may need to actually include it in the specs. If I had not learned programming, I would have never even considered this as a possibility, let alone include it in my designs.
Another I did not know was that you could actually add custom styles to focus rings, the blue rings that show when you press the TAB key on most webpages. If the blue color doesn’t look great with the rest of the website, why not change it? I was also not aware that once you could style a Google Map with the Google Maps API. In fact, here is a website that has all sorts of styles you can just pick from : Snazzy Maps! The default map itself has a great design, but sometimes you may want to emphasize something more, or style it to match your brand colors.
Suggesting Original Features
If you are designing an app that uses fairly newer technology, chances are there aren’t a lot of apps out there yet for you to reference. For example, I am currently working on a live broadcasting app called PRISM Live Studio, and to be honest, it’s hard to ideate new features when you don’t know what’s possible.
Now that I know how to use Github, I’m learning that I do not have to limit my design research to apps that have already been released. I can download any open source project that seems appealing to me, try it out, and build my ideas from there!
I also realized that I could now resort to API docs, the source code, and other types of technical documentation to help me better understand technical limitations.
For example, our app uses the YouTube Live Streaming API to connect and publish broadcasts to YouTube. Even though I still consider it better practice to delegate most of the spec validation to the developers, I have realized that if I am in a real hurry, I can now check things out for myself. I can just simply pop open the API documentation, look up the maximum resolution that YouTube live supports, and include that in my description of the resolution selector component in my design.
I believe a designer can still design without code, but taking a deeper dive into how things are built definitely is opening up a whole new world of design possibilities. If you have been contemplating on learning programming, I hope this article has helped you visualize how it could impact your current career.