Career Design Software Engineering

It’s not my job to care what the product looks like, or is it?

Well it doesn’t look pretty, but we’re not designers anyway…it’s not our job.

-Software engineer intern

I overheard one of the interns earlier this summer talking about the project he was working on when he was updating his mentor on his progress. He was working as a client-side iOS engineer for the summer and didn’t seem to think it was his job to make things pretty, just functional.

While there’s a certain truth to the fact that engineers don’t have to come up with good UI/interaction designs for their products (at least at large software companies where there’s dedicated designers for this purpose), this doesn’t necessarily mean that they should turn a blind eye to their “ugly” but functional work.

For front-end/client-side engineers, there are two things that I’ve observed that the best engineers do:

Work hand in hand with their designers to come up with the best experience but DON’T hinder the designer to think big.

In general, the ideal workflow goes something like this:

  1. Based on the requirements, designer and engineering team brainstorm different ideas for the product
  2. Designer takes an initial stab at the designs (alone) with the brainstorming feedback from the team
  3. Designer sits down with engineering team to do a first pass over the user interface and user interaction mockups
  4. Designer takes team feedback and iterates on his mockups
  5. The engineering team does another pass over the new designs
  6. Steps 4 & 5 repeat until both sides are happy

As someone that’s taken a stab at being an interaction designer from an engineering background, step 2 is a particularly important step. This is what is necessary to allow a designer to dream big and not get their ideas immediately shut down by the engineering team. Engineers are generally limited by what they think is technically possible. However, I often see instances where an engineer will tell a designer “It can’t be done” and come back later and say “Wait, I think I figured it out.” They just needed a little bit of time to think (or Google around for an answer) and a bit of inspiration from the design itself.

That being said, the rest of the steps are to bring the designer back down to earth and find a common ground between the design and engineering teams. Sometimes things actually aren’t technically feasible, or there’s just not enough time to implement everything the designer wants.

Push back against designs that just aren’t good enough.

Even though your designer is probably great at his job, he doesn’t always have the right answers to everything. If there’s something that just doesn’t sit right with you as an engineer, say something, even if you don’t necessarily have a solution for the issue. Likely, others on the team will agree with you and then together, the team can find a better way of doing things than sticking with the original idea.

When both the engineers and the designers have a say in the UI, everyone will be much more invested in building a great product. Otherwise, if the product doesn’t turn out quite the way everyone envisioned it, you may have a case of the blame game on your hands – “The designer just didn’t do a great job with the interactions” or “The engineers didn’t understand me and built something completely different.”

Building great and beautiful products is definitely a team responsibility. While everyone has their own roles on the team, that doesn’t mean that as an engineer, you shouldn’t get any say in the design (if you want it). The best designs are not “thrown over the fence” and given to the engineers to implement. The best designs are iterated on, pushed and prodded, fiddled and tinkered with until it just works…for everyone.

2 thoughts on “It’s not my job to care what the product looks like, or is it?”

  1. Hey, I love all of your tutorials on watchOS. Super helpful and much appreciated. I do have a question for you, which perhaps might be a good topic for a design-centric tutorial? I’m curious how you would approach trying to create an interface like the default Photos app for the watch. Given that in watchOS you have to predefine all of your UI elements in interface builder at design time, I’m a bit stumped on how build a grid like display that adapts to a variable number of images and also allows paging and zooming the way the Photos app does. All I can think of to do is to create an interface for a max number of elements (nested groups?) and then hide unneeded elements at run time and adjust heights on the remaining elements. Do you think something like this is possible with nested groups? Or is there a better way to approach it? Or do you think Apple is using private APIs? Any thoughts appreciated, and thanks again so much for the tutorials, they really are great.

    1. Great suggestion! I haven’t seen anything allowing zooming on the Apple Watch (aside from accessibility options) so that may be a private API thing. I know apple does cheat a bit and use private APIs – the watch weather app, for example, shows a small loading indicator while grabbing the latest data from the web. None of the 3rd-party apps have access to anything like that so they have to make their own custom loading experiences.

      For paging, you can probably use this tutorial with some tweaking. It seems like you’ll have to have a set number of Interface Controllers with this approach though so you may have to get creative if the data set you have is over/under the number of Controllers you create.

      Hopefully, watchOS 3 will give a lot more flexibility with the APIs. I’d love to hear if you figure it out with watchOS 2 though. Good luck!

Leave a Reply