Thinking like a developer, part I: think in code

I always had an infatuation with coding and product design. Yet, looking at job descriptions, it was hard to fit under one title.

My designer self loved the font Helvetica and doodling in my sketch book with a fountain pen. I was also fascinated with how UX Design had gained prominence in the world. Like Maria Giudice wrote, design leaders were emerging as DEOs along with CEOs. People cared more about how technology was affecting their being. Just as Julie Zhuo predicted, users chose one product over another ‘because of style and how it made them feel rather than pure utility.’

 Rise of DEO is an inspiring  book  by Maria Giudice about leadership by design.

Rise of DEO is an inspiring book by Maria Giudice about leadership by design.

Meanwhile, my developer self wanted to understand how the blockchain worked. I loved the practicality, speed and scale that came with software development. The simple recipe of making a website from scratch. The instant gratification of pushing code online. Having reach to 3 billion people on the Internet with one commit. With all this combined, the relative impact of programming was immeasurable.

Here is a secret I learned: You can design technologies and use coding as your superpower. As design and engineering communicates better, your team moves faster, you iterate more, and land creative as well as feasible solutions. So, I started as a software engineer ‘with an eye for design’. Then I took on hybrid roles that combined front-end development and design.Currently, I am a designer who can think like a programmer.

How can designers THINK in Code?

If you are a UX designer, developers will implement your designs in code one day. Your mocks will become parts of programs that reach real users. One thing that helps with this process is thinking in code. That is putting yourselves in the shoes of the developer. Here are two practical ways you can adopt the superpower to think and talk like a developer.

Mix and Mingle

Quickest way to start thinking like a developer is working closely with them.My team, Periscope, sits under Twitter’s Video Org, and we operate like a startup within the larger company. We organize bi-weekly board game nights and pingpong tournaments. We even have a basketball team! Team spirit forming starts at the lunch table, and ranges from making flower arrangements for mother’s day to having team all-hands.

Despite how much us designers like our displays, we make an effort to mingle with engineering. The cross-pollination between engineering also begins at an informal level.We get to know each others’ language through discussing the graphics of the latest video games. Then we have weekly, sometimes daily, project syncs. During these meetings designers, as well as client engineers (iOS, Android, and Web), share their progress on what they are building.Engineers ask for creative guidance if they are working on an unforeseen error state. Likewise, designers get feedback on their designs regarding engineering cost and constraints.

All in all, working closely with engineers is the first way designers will learn the technical lingo and start to think in code. Getting exposed to engineering ideas makes sure you don’t waste time in perfect Design Land. This way you move away from ideas that are impossible to build. So, you have more time to explore the feasible design space. You land elegant as well as workable solutions.

Prototype: Visual Programming

Another way to empathize with developers is to use visual programming for prototyping.

 Origami, one of the best visual programming tools for designers.

Origami, one of the best visual programming tools for designers.

What is visual programming?

I am a visual thinker, that means majority of my ideas come in the form of pictures. When a concept gets complex, I reach for the white board to draw it out, to explain it to myself and to others. Similarly, visual programming illustrates how components of a process relate to each other. An easy example that everyone is familiar with is a flow chart. In contrast, text-based programming flows line-by-line. Like the command-line tool; the green and black interface of the Matrix.

Why use visual programming to prototype?

If you are a visual thinker, like many UX designers tend to be, visual programming will come to you naturally. Also, using these tools, you will build an understanding of how each button and screen relate to each other.You will understand what components make up the big picture and how logic flows through the prototype. So this is a great way to build empathy with developers, who live and breath in Number Land.

 This is why we call Origami Noodle Soup 🍜

This is why we call Origami Noodle Soup 🍜

On my design team, our go to prototyping tool is Origami Studio, also known as Noodle-soup. There are practical reasons why we prefer this tool. First, you can copy paste designs from Sketch and preview on a device using the iOS app. Second, a vast library of patches is available, including option switches and built-in animations.

Looking to get engineering or stakeholder buy-in? Powered with Origami and similar tools, possibilities of what you can prototype are endless. You can explore a wild range of ideas from building a voice recording tool to a native camera app in a few minutes. Go out to the wild, build your crazy idea, and illustrate how innovative your concept is! If your design fails while you try to put it in numbers and patches, let it evolve or pivot to another.

“If a picture is worth 1000 words, a prototype is worth 1000 meetings.” — saying @IDEO

 

 he long-debated question: Should designers code?

he long-debated question: Should designers code?

I used to believe that thinking in code while designing restricts creativity. I wanted my designs to be unprecedented. I knew that conciseness and reusability in programming were important. But I did not see the link between unique designs and the systematic way of code and logic.

As a designer with an understanding of code, the more I bring what I know from programming into my design practice, I am able to move faster and iterate more throughout the process. Through the engineer-designer feedback loop, considering the engineering constraints and designing for edge cases, I grow as a designer.

Here is Part II: Design the Edge Cases.