Something like that

Designer as Developer

Hey, I’m Kaspar So. I’m a design student currently working as a developer.

For the past month and a half I’ve been working (gone undercover) as a developer for a larger newspaper company. I started this job coming off my second year of a four year Interaction Design program. My goal for the summer was to work closer with developers as the relationship between designer and developers has been, and still is, a growing interest of mine. When being offered a developer position (official title being Digital Products Developer), I realized that it was a great opportunity to gain perspective from a developer’s point of view. Taking on the role, my experience in web development was limited, but I was confident in my ability to learn on the job as I often found myself coding my prototypes rather than building examples in a motion graphics tool, like After Effects. This article is a brief reflection on a few things I have learned so far.

I feel like starting a new job is like figuring out where you fit within the current production cycle/process. Being a newspaper company, there were established ways of how things were done, with people that have been working here for 20+ years. My goal was to understand the current process and see where I can insert myself. When I explain the process here to some of my friends, they find it odd that it’s so different from what we had learned. Coming from design school, I’ve heard of my fair share of normative workflows.

“We’re designers, we’re supposed to disrupt the process!”

While I don’t oppose the processes we’ve learned, I understand that designers can be overly ambitious at times. The reality is that this company might have adopted a unique process due to their established past. I have to understand it before even trying to change anything.

Get Close

It’s hard to work with designers and developers if they’re spaced out. The layout of my work has designers sitting across the newsroom to where my team sits, which results in either us going to them or them coming to us for any type of review. This sucks when it comes to UX/UI refinement as each tweak is a suicide sprint.

Distance aside, our designers work overtime as they design for more than just our team. This doesn’t serve well to developing functionalities first, UI second, as designers coming in closer to the end of the production process often results in rebuilding some components, simply because they weren’t continuously a part of the development. By having them closer, a more constant dialogue can be had.

*This could just be an issue of not enough designers. A temporary solution would be to give the developers more creative control, as a couple of us come from design backgrounds. It’s temporary and not necessarily scaleable, but it could be useful to push us through the heavy project seasons.

Don’t “Just build both and we’ll see”

This is conditional, as changing a single button from a circle to a square isn’t hard, but building two finished versions with different UX/UI is just unnecessary, especially for our team size and workload. I much prefer the methodology of building out a MVP, or Minimum Viable Product, and iterating. This keeps forks in the road smaller, and less of a surprise. Furthermore, building multiple versions that are not iterations of one or another sets a bad precedent for the way your time should be spent, as there are always more projects to work on.

Instances are Nice, but <strike>Diamonds</strike> Tools are Forever

Working at a company that is constantly pushing out content (in the form of articles), building for reusability is key. While it is nice to build a super customized end product, I’ve learned that thinking about your projects as reusable components, rather than one-offs, will yield more value long term. Allowing writers to have access to tools means you build more autonomy in their daily workflow, rather than them coming to you every time they need to visualize something. As such, from a designer perspective, it would be a nice challenge to think about designing for tools and being able to adapt them to multiple contexts.

Ultimately, this list serves as a reminder to future Kaspar, the designer. Things to remember when communicating with devs, and understanding their perspective when the topic of iterations, special features, and multiple builds come to mind.

Thanks for reading. My goal is to use Medium to write about my experiences and share what I learn as I journey through my design career. I may not always be right, so let me know what you think. Feel free to get in touch and expect another article soon.