There Is Always A User

A Blog on WWCode NYC Tech Talks: User, Design, Tools @ BuzzFeed

What were you thinking when you wrote that code? Were you thinking of how to optimize run time? How to make it less repetitive? How to load less frequently? About how your user…wait you’re a coder. That’s the job of the graphic designer. You don’t have to think about that, right?

I bet you never really gave much thought to your user did you? Your user isn’t always your company’s user, but there is always a user to your product. As a programmer, I never thought very hard about my user. Or rather, I never asked myself really meaningful questions about who my user could be — especially when creating internal tools.

This blog post aims to summarize my take on the tips, best practices, and some very important questions you should be asking yourself that were discussed at the WWCode NYC “User, Design, Tools” Tech Talks at BuzzFeed.

Building for your company’s user: -By Liis Peetermann
Creating a user interface? If so, it is important to know who your user is, and be as close as possible to them as for feedback. If your user is an American, having an office in argentina won’t help you understand them better or get good user feedback about your intended market. If you’re hanging out at Starbucks, ask strangers to click through your site and give you feedback. You’ll realize things you thought were obvious are not intuitive to someone new to the site.

Building internal tools for other departments: – By Sabrina Majeed – Design Manager & Nicolle Matson – Product Designer
Building a gui that aggregates multiple ad APIs? The same situation applies whether you’re designing for your company’s users . Be as close to your user as possible. BuzzFeed developers shadow other employees, literally sitting next to them and watching their day to day processes. You have to see what they use and how you can improve their workflows. If they have a question they can just walk right up to another’s desk and discuss their problems with the software. Even being in the same building and even better, on the same floor can drastically improve the product and troubleshooting. Physical proximity is vital.

Building internal tools for other developers: – Emily Brick – Designer Lindsey Maratta – Designer
The code will speak for itself. But it doesn’t speak English so we really do need to comment our code. In fact, your code may be speaking in several languages if you’re part of a multinational corporation. If so you’re going to want consistency starting from your page layouts to your project structures. BuzzFeed’s approach was to create internal tools that standardized a lot of the page styling. They called one such tool, “solid”. It atomized css classes and allowed developers to integrate the code into their html. It was designed to be integrated and expanded quickly, so that after a week or two even new employees could add to the “solid” module. And all the changes are documented in an easy to view internal site or application.

Summary
Go to tech talks. They are really informative and motivating. Who will be your user? Is it a consumer, another department, or another developer? How the user is going to interact with the product? What is your user’s workflow/day-to-day life and can it be improved? Whatever industry you’re working in, get as close as you can to your user and take the time to ask yourself these questions as thoroughly as possible. You may not write “better” code, but you will build great software. And that is the mission of any great coder.

A big thank you to BuzzFeed, Women Who Code, and our speakers for hosting such an amazing event and giving female developers insights into the importance of designing with the user in mind. It’s always a fun and enlightening experience.