I used to be confused about whether I should introduce myself as a front-end developer or as a designer. I would switch back and forth based on the situation and whom I was talking to.
Applying to a design studio? I better call myself a web designer. Being interviewed by a software architect? “Hi, I am a web developer!”
Then I found my dream job at a large design studio:
Me: “So would I be a front end developer or a designer?”
Recruiter: “Both! Everyone here is a designer, but your discipline would be front-end development.”
Me: “Crap. I’d better take a design class then.”
Semi-Pro Tip #1: Do not mention that you have never taken a design class to a design studio recruiter.
Feeling intimidated by designers
So I immediately registered for my first design class to take during my final semester of college. The class helped me grasp some basic user experience concepts, but I still ended up reporting to my new job at IBM with a major inferiority complex.
I entered the role surrounded by research, visual, and UX extraordinaries. They were all focused on user pain points.
Contrast this with me. As a developer, I was conditioned to just ask which features I needed to implement, then decide how best to do that.
Anxiety started to overtake me. I started to think that maybe I had made the wrong career choice.
Maybe I should have joined a department of strictly developers.
Maybe I should have joined a studio that hands off designs to developers without expecting their feedback in return.
Or maybe I should have just given freelancing a shot for a year before joining a large multidisciplinary team.
On the job, this anxiety resulted in shyness.
Semi-Pro Tip #2: The f-word in design is “feature.” There is no product correlation between the amount of features and the quality of the user’s experience.
Learning to walk both worlds
Luckily, IBM Design had a three month entry-level design bootcamp, which taught me that I could be both a developer and designer. So I soaked up skills from my peers and absorbed as much of their expertise as possible.
The program forced me to take part in activities that helped me understand our users. That’s when I fell in love with the process of writing user stories to document their struggles, then trying to solve them using my development skills.
One key takeaway was that our team became more successful the more time we spent together. There was always a temptation to split up to work alone, then come back together. But we had to fight that.
Pair programming with a visual designer helped me greatly. It taught me more visual principles than reading any intro to UI patterns book I could find. At the same time, the visual designer — who had previous worked in print — could learn principles of responsive design quickly from me.
Throughout the camp, I learned the true power of multidisciplinary teams. We taught each other about research, user experience, visual design, and front-end development — all in a natural, conversational way.
Teaching developers how to think like designers
A couple of months after graduating from the design bootcamp, I was given the opportunity to attend a college hackathon as a sponsor.
The event was filled with developers who wanted to make epic solutions for various problems. I thought I was there to help participants debug their web apps, but I ended up helping a lot more with design.
First, a guy came over to show off how he had already used an API to visualize some data. After congratulating him on this technical feat, I asked him what his user goal was. He admitted that he had no idea. So we started writing hills based on IBM’s Design Thinking docs.
Next, another developer wanted help with their color choices. A year ago, I would have been the absolute worst person to ask for help with this. But I didn’t flinch. I asked him what he wanted the web app colors to communicate.
Dev: “What do you mean? I just know that our color choices are ugly.”
Me: “Ah, you are talking about styling. Your colors can do more than just make things look pretty. Why would a user not want to use your app?”
Dev: “Well it is a money management app. I don’t know if people will trust us to handle their money.”
Me: “So let’s see if any research has been conducted about colors that resonate with trust and money!”
With the right question in hand, we were well on our way to researching and selecting the right colors.
The second day of the hackathon, I talked with a team was killing it and getting better with every iteration. The team already had a complete “cupcake” (full experience, but minimal version) of an app. They knew it was time to gather feedback, but did not know how to go about doing this.
This turned into the perfect chance for me to walk them thru their first user testing session. The team learned to provide simple goals to the user, one at a time, then ask the user speak out loud their thoughts during every interaction and every screen.
Semi-Pro Tip #3: If your user is not vocalizing their thoughts to you, how will you know what they’re thinking?
So what am I, then?
So who am I? Thanks to my studio’s design training , I now feel qualified to say I’m a designer. But doing this does not marginalize my role as a developer. Instead, I am now able to touch a product’s growth from the first research interview all the way to the production code we ultimately release.
So what are you? Are you a designer with a background in data analysis and/or visualization? Are you a designer who understands product strategy?
I encourage you to engage with full-time designers in your organization. Offer to share your strengths with them. Then stand back and learn from theirs.
For further information: Feel free to contact me by the comments, email, or @seejamescode. I work in ATX for IBM Design and always love conversation with the web design community. Also be sure to share your own career identity crisis in the comments!