Technology Intensive
This is the 3rd post in a series of posts recapping the courses in my UX Design graduate program at MICA.
Date: January 10th — February 2nd
I just wrapped up the third class in my graduate UX program at MICA. 3 classes down. 6 more to go. The first third of this program covered a variety of topics. In Foundations I got my feet wet. HMI taught me that UX is more than just what’s on a screen. And my most recent class, Technology Intensive, was similar to the foundational course but dove much deeper. We touched on the parts of a UX project from start to finish and zoomed into specific project deliverables while learning many tools of the trade.
Each week was a part of a UX project. We created specific deliverables while planning, researching, designing, and testing our idea. We documented our work and the tools we used along the way.
Planning
Recently I stumbled onto “10 foot UIs” which is a user interface experienced from 10 feet away. As smartTVs are becoming more popular, 10 foot UIs are becoming more common. I recently bought an Amazon Fire TV stick and was delighted to know that I could play Spotify through their TV app. I loved being able to easily stream music from my phone but using the native Fire TV remote to navigate the application proved to be difficult. I was passionate about the music listening experience, especially as an avid Spotify listener, so I decided to look into why I experienced the problems I had and how I could design a better solution.
I looked into why this problem was occurring by performing the “5 whys” exercise. Instead of taking the issues at first glance, I asked myself why things are the way they are and stumbled onto the root cause. The interface was very simple and native users weren’t able to easily navigate comfortably with the four way directional remote. Information density should be low because this is a “casual consumption” experience, but music listeners wanted precision and choice. Many users preferred to use their mobile app but users who use the remote should still be able to have a efficient and delightful experience.
I divided up the month into time for research, design, testing, and feedback. I defined the user requirements, project goals, and tools that I would use along the way.
Research
I first looked into app reviews on amazon’s website. There were hundreds of reviews for the app, 200 within the last two months. I read both good and bad and got a sense of what worked, what people liked, and the issues people had. This one review pretty much sums up the problem.
“I’m not a big fan of apps that force you to use your phone/tablet for navigation because creating a good UI for the remote would be too hard” — Johnathon Mayeron, Oct. 3rd 2016
I then decided to send a survey to the r/Spotify subreddit which I frequent quite often. This dedicated community of not only passionate music listeners, but big fans of Spotify as a product, gave me detailed insight into how they listen to their music. The survey got 88 responses and I found out what features in the “Browse” section they liked and what song identifiers (artists, albums, song titles) they look for most. I took this information with a grain of salt, knowing I need to validate them in the design phase.
I also read the design guidelines from Amazon, Apple, and Google for their TV platforms. They all covered common topics like typography, navigation and layout. This helped guide my design decisions and informed me of common design patterns.
Design
I focused my design on the navigation of the interface. I decided to add a second row of items that lets you move from menu to menu without having to click through each column. The content area displayed more items from that menu which supported decision making by giving listeners more insight as to what was in each category. This grid of items was also easier to navigate. More songs could be seen at any given time which lets listeners see more items with less scrolling.
Looking back, there are changes I would make in each stage of the project. I would adjust the survey to be longer and adjust the questions so answers wouldn’t fall to the self reporting error. Often times, things respondents say in a survey, aren’t exactly what happens in real life. I would follow up with participants in the survey for testing as opposed to getting quick feedback from classmates and friends. I also would’ve made more adjustments to the design and a more interactive prototype. Unfortunately, this class only lasted a little over three weeks. I will try to come back to this project and add to the prototype. I’d love to add the ability to select an album, scroll through songs, and actually be able to play music.
Here is a list of my classes. I’ll be covering each class in an article much like this before the class is wrapping up. “Prototyping” starts next week.
