• Women 2.0 HowTo Conference San Francisco, September 30 - October 1, 2014

The Evolution of Design From a Non-designer: Getting Started

8489053357_aea3be2cc6_c

A design-challenged software engineer decides to take over every aspect of product development at her new startup. 

By Tessa Ann Taylor (Founder, Co)

When I set out to build my own app, Co, I knew I had quite the task in front of me. I decided I wanted to oversee every aspect of the app development, from the design to the code to the deployment. I’ve spent most of my career building products with incredibly talented teams, and so the idea of taking over every aspect of product development was…daunting.  I’m a software engineer, so that part didn’t make me nervous, but I am not, and have never been, a designer.

Let me back this up a little bit – it’s not that I haven’t tried my hand at design. In college, I took a few art classes (photography and digital media). Technically these classes had a drawing prerequisite, but I asked (and received) permission to waive it. I know drawing isn’t my forte, and I didn’t want to waste everyone’s time by spending a semester on it. At some point in one of my other classes, we had to do a brief (mercifully ungraded) sketching exercise. The professor came up behind me, looked at my page and said, “Wow, it’s a good thing I let you off the hook for that drawing requirement, you really can’t draw”.

So maybe I can’t draw, but when you’re working with a team, you’re able to rely on the talent of the people around you. When you’re running the show, however, “can’t” is no longer a viable excuse. When I need something done regarding the app, either I have to figure out how to do it, or it doesn’t happen.  Since design is one of the things I needed done, I had to figure out how to do it.

So, where to begin?

Like much of the world, I’m pretty quick to point out design I don’t like. While that’s a start, the “I’ll know it when I see it” approach doesn’t work when you’re the one responsible for coming up with the design. Instead of focusing just on what I don’t like, I started to cultivate designs that I do like. I went in search of apps, websites, art pieces, coffee tables, etc. that I did like, and figure out what I liked about them. Were they functional? Fun? Clean? Unexpected? Beautiful? Could I learn anything from this design? Could I incorporate something I learned into my app?

Instead of focusing on my weaknesses, I set out to find my strengths. Part of product design is making something beautiful, but another important part is to make a product that is easy to use. This ease-of-use is where I have focused a lot of my energy – every detail of every screen is under a great deal of scrutiny.  What is the primary goal of this screen? Does this button/color/piece of text aid in that goal?

The conclusion that I’ve come to is that that one of that most important parts of design and functionality isn’t what you add, it’s what you take away. The evolution of Co has been a clear example of this – my early prototypes had a LOT going on, both in functionality and design. As the product has evolved, each iteration has been an exercise what to remove, rather than what to add. Forcing myself to keep every aspect of Co as simple as possible has kept the design, etc within my abilities, and ultimately it will result in a streamlined product that is easy to use and a pleasure to look at.

This post originally appeared on the Co blog. Image credit: marco via Flickr

profile3sAbout the blogger: Tessa Ann Taylor is the founder of Co (http://coapp.co), a technology company that aims to simplify mobile messaging. Before founding Co, Tessa worked as a freelance software engineer, specializing in web technologies. Tessa currently lives in New York City.