Beyond Code: How UX and Visual Designers Can Get Involved with Hackathons

The other day, I was meeting with a group of fellow women in technology when the subject of hackathons–or design/dev sprints–came up in conversation. The group had been discussing potential activities to get involved with and to my surprise, some of the people present were unaware that non-coders could be valuable hackathon members. Hackathons are traditionally code-oriented; however these events draw a variety of participants from diverse tech backgrounds.

If you search for hackathons via search engine or Twitter, you should find upcoming events, many of which sponsored by big organizations in exciting industries. For example, NASA is presenting one of the world’s largest hackathons right here in Pasadena, CA: the NASA Space Apps Challenge.

For those of you who are design students, hackathons are a great way to meet other likeminded people in technology and to build your portfolio. When I talk to design students who recently finish their programs, I truly stress this tip–particularly to those who graduated from programs such as General Assembly. Be aware that many student portfolios will look the same content-wise. Students need to stand out when looking to land that gig.

diana barraza hackathon ux ui

For the UX or UI designer looking to get involved with a hackathon for the first time, it would be a good idea to acquaint yourself with Google Design Sprints. This isn’t the time or place for working on complex personas or scenarios. Instead, use your UX ninja skills to look at the task at hand and take on the following:

  • Hone in on the problem. What challenge is the hackathon looking to address?
  • Get your ideas down on paper. Sketch out a few variations once you understand what your focus is, what elements of the product are you looking to include and who your users generally are.
  • Raise the fidelity. Chances are you will be presenting a prototype rather than a fully-functional app or product. Your UI skills will be sought after amongst coders or project managers. I remember attending a hackathon and a group presented their code. That was it. It’s great to see the work, but this doesn’t quite emotionally resonate with judges and hackathon attendees.
  • Get involved with the presentation of your design. This is a great opportunity to discuss your design decisions and how this addresses the problem.

If you have the time and the drive, start looking for upcoming events. Thankfully, the Jawbone Codeathon that I attended back in 2015 stressed rest, exercise and healthy eating. Be prepared that not all hackathons or codeathons offer drip coffee and quinoa. If you want to read more about my team’s hackathon win, take a look at the story on the General Assembly blog. Happy hacking!

There’s No Express Auto Lube for UX

diana-barraza-ux-ui-design thinking-diana barraza

If you’re a car owner, taking your car in for an oil change is like a game of Russian roulette.

You think you’re getting the $25 special, but after the courtesy check, the mechanic comes over to you looking pensive, clipboard in hand. He sits down and gives you the tough news: your tires are bald and your brake pads are worn to the minimum thickness. All of a sudden your $25 trip has now become a very expensive trip.

You’re on the verge of crushing your latte cup after hearing the news, but you realize he’s not trying to ruin your weekend, he’s trying to keep you and your car safe on the road. Begrudgingly, you sign off on the repairs.

I imagine this feeling is similar when we bring up topics like research or user testing with clients.

“How much is this going to cost?”

“I think I know my MVP–why is this necessary?”

Simply answered, it’s not until we research and test that we can actually validate both the client and the designers’ assumptions. Prior to this, we don’t know if our “tires” or our “brakes” are any good.

There is no express test station for UX. We can’t hook your app or software up to a machine and give it a quick audit. We can’t print out a “pass” certificate in ten minutes.

The reason this is the case is because we are dealing with user emotions. We are dealing with people so it’s worth putting a prototype into human hands.

There is a familiar saying in the UX field: test early and test often.

So many times I go to Meetups and events, hearing from designers that their respective places of work don’t really do research or testing. I shed a tear into my complimentary beer for this common gripe and thank my lucky stars that’s not the case at our studio. I have heard from designers who have never had experience doing research and testing because of this.

Much like that car in the shop, testing and research will save the stakeholder from even more costly repairs down the road or worse: total failure.

Many apps fail. Many apps are downloaded and only opened once.

So, trust your UX mechanic, a thorough check up will save your wallet and your product in the long run.