Design Log: December 2016

Thursday, December 21, 2016

I just finished Creative Confidence by Tom and David Kelley, and I’m so glad that Amazon recommended this book to me. I don’t think I’ve learned this much from a book before. Though every chapter was loaded with fantastic information, I think my favorite part of the book was Move, which talked about all of the different design activities that IDEO utilizes. Though all the activities sounded great, the ones I think I’ll continue to use the most are…

  1. Mindmapping
    • Mindmapping is an activity that helps open the mind to new ideas as well as map an individual’s thought process and record the evolution of an idea
    • Mindmapping also facilitates divergent or unconventional thinking and idea generation
  2. Empathy Maps
    • Empathy maps are based on what people say and do, and should help you draw real and valuable insights on what they think and feel
  3. Customer Journey Mapping  
    • Customer journey maps help an individual think through each step of what they would ideally want a customer to do
    • It’s helpful to be able to “journify” the process for both customers and stakeholders alike

I’d recommend this book to everyone – it’s not meant for just “creative types.” Regardless of industry or background, anyone can apply design thinking to their jobs.

Monday, December 19, 2016

Today, I spoke with a user researcher at Microsoft to learn more about how user research is conducted in other teams. Tools they use include Survey Gizmo, MAXQDA, UserZoom, UserTesting, and others. Microsoft also has their own participant recruiting arm as well as a team that’s dedicated to recruiting test users specifically for games.

In terms of how someone could get into user researcher, the most traditional way is getting a graduate degree – Masters or PhD – in computer science, human-computer interaction, etc. Post-grad work is generally research-heavy, so you’ll be learning how to do research in one way or another. Other ways of getting into user research (though not as common) include doing a product management role that works closely with research and design, or a product design/UX role that works closely with research. It definitely depends on your team.

Advertisements

What I learned from my first UX Hackathon

Last summer, I attended the first annual SoCal UX Camp, hosted by both the Los Angeles and Orange County User Experience groups. The event was packed with people, but as a college student, I noticed that there weren’t too many others who were my age. I met a couple of people who have been out of college for a while but were looking to try something different and dabble in the emerging and exotic user experience industry.

Though a lot of people who currently work in user experience come from IT-focused backgrounds, many of them are also graphic artists, journalists and even anthropologists. Unlike programming, which people looking to transition into more tech-related jobs think they’ve missed the boat on (though some think the opposite), UX  is a way for people to hone in on a certain skill and really get good at it. Plus, since user experience is starting to become popular as a singular industry (though the concept of user experience has been around for quite some time) these days, even if you start tinkering with UX now, you can still catch up quickly.

This brings me to the subject of the UX Hackathon hosted by General Assembly in Los Angeles on Sunday. A group of USC students decided to attend after word about it traveled about our group of techies here.

When students like us think of “Hackathons,” we assume that most everyone in attendance will be around our age (or, in the instance of HackTech, even a little bit younger). But at this UX Hackathon, there were a lot of adults. At traditional Hackathons, even if the age range is wider than usual, it usually doesn’t matter. If you’re young and brilliant, you still have a chance against someone who might be older and more experienced. But since UX design, in addition to having an eye for it, gets perfected with experience and time, being younger put us at a slight disadvantage — but we weren’t disheartened. The three of us teamed up with three others and, after the introductory speech, we went to work.

No students to be found at the UX Hackathon.
No college students to be found at the UX Hackathon.

Unlike traditional hackathons, instead of being assigned or choosing to incorporate a specific API into our project, we randomly picked a topic and a “wrench,” or a guideline we had to follow, from bowls. We ended up getting sports and “the end-of-brick and mortar” as our wrench. A little confusing, but do-able nonetheless.

Not to mention, we didn’t have a whole weekend to come up with this project. We only had five hours to brainstorm, research, plan and design.

We dedicated the first half hour to research. After doing some competitive research on compete.com, we looked into franchises that specialized in sports equipment and merchandise. At the time, we still weren’t clear on what the exact rules were even after the presentation, so we decided to put a spin on our wrench and take the concept of pickup games and turn it into a mobile app. Each member in our group agreed, and we started working on our own tasks.

However, two hours or so into the event, mentors started coming around and asking about our project. One of them handed out a sheet of rules that we hadn’t seen before, and we started realizing that perhaps we weren’t going about this in the expected manner.

The paper that almost pulled our team apart.
The paper that almost pulled our team apart.

Then the disagreements started happening. Two of our members decided that we should go back, scrap our work (nearly completed mobile app designs, a working website and our presentation) and start over. The other two, who had been toiling away on their tasks, were ready to split. To keep the group together, we made compromises and decided to base our app, TeamUp, on our interpretation of meetup.com‘s sports meetups.

Time was up before we knew it, and we walked into the main room to hear the final presentations. There were redesigns of Epicurious, Southern California Edison, Sephora and other pretty big names. The level of professionalism, to our relief, was across the board, from people experimenting with UX to very seasoned professionals. Our team was third to last to present, so patience was running thin in the air. Nevertheless, we gave it our all and just like that, we were finished.

Brainstorms such as this one mostly covered the white board walls at General Assembly.
Brainstorms such as this one covered the white board walls at General Assembly.

Aside from what I had observed earlier on, there were many more differences between a UX Hackathon and a technical hackathon than I had previously thought. The minute we thought of our own idea, we started getting lost in it. We focused a lot of our efforts on the branding, name and look of our product, and though it turned out looking incredible, by coming up with TeamUp, we only covered the “Hackathon” part of the “UX Hackathon”. After seeing which teams the judges picked as winners, I realized that all we had to do was make a website easier to use for the end-user. We got too caught up in our ideas and forgot the whole purpose of UX.

Though everybody on our team was great, it’s difficult to tell, when meeting people, what their working styles are. Though this difference didn’t hurt our team, the way each of us worked sometimes clashed. When we were forming groups, we let people come to us, and ended up maxing out the number of people on our team before we actually got to mingle with others. Unless you’re coming to a hackathon with a team already, make sure to meet people before settling on your final team (but don’t dawdle for too long or you may not have a group!).

As for our presentation, in school we’re so used to having each person in a group project speak that I had forgotten the same doesn’t always apply at hackathons. Most, if not all the presentations, had delegated the speaking portions to one or two people, which made the presentations more fluid and paced. Because we had six people speak on our team, things got a little harried and we just barely ran out of time.

Despite the ups and downs we went through as a group in just five hours, we did a pretty good job despite the fact that we didn’t place. But something tells me that there will be many more UX Hackathons in the near future, if the trends in UX and hackathon popularity continues in this way.

Curious to see our presentation? You can view it here. Graphic design credits for our mobile application go to Grace Duong and design/coding credits for our website go to Stephen Chen. Presentation designed by yours truly.