MI 420 Process Blog

MI 420: Interactive Prototyping, MSU FS17, Hannah Countryman

[hl7mi420]

Digital Dashboard Digital Prototype

This has been a challenge. It’s an interesting one, and one I intend to continue thinking about and working on over break, because I know my design is not where I want it to be. I realized I don’t have as good of a grip on working within Axure as I thought, and some of my ideas didn’t work out as well as I’d hoped. But without further ado, let me tell you about my project.

I chose to start by recreating pieces of my paper prototype and the physical interface in Sketch, which lets you create graphics superior to Axure’s but offers no options for designing interaction. I found, however, that I was thinking a lot about the details of design and not enough about the overall interface, so I jumped out of Sketch after putting together my basic homescreen and physical space and I went to work giving these elements interactivity.

I created masters and used hot spots to add functionality to the images I’d designed and exported as PNGs from Sketch. I was proud to get the first set of images on the side to scroll both using the arrows and on swipe. However, I ran into trouble trying to get my focus to work the way I wanted it to.

I tried a variety of different variable combinations, attempting to get my volume slider to function as I wanted it to. I Googled solutions, but couldn’t quite figure it out. I’m sure when I come back to it I will be able to eventually get it working, but I chose to instead focus on other aspects of the design that I knew I would have more fun creating and that would turn out a wholesome final piece, despite imperfections.

Make sure to check out the animations in the Talk to Tom screen and to give one of your favorite contacts a call. Thinking about how animation and loading indicators worked was an interesting part of designing the user experience for me. While my initial focus didn’t turn out as planned, I have a better grasp on how the micro-interactions and subtle animations may indicate to users what is going on behind the scenes.

I tested these cues with my dad, a 55-year-old father of two who probably would’ve appreciated the helping hand of Tom, the car’s AI, and easier ways to navigate a vehicle’s features despite bickering children in the backseat.

He wasn’t especially familiar with the idea of asking a digital AI to take you somewhere or answer your questions, so the Talk to Tom screen was initially confusing and required some explanation. He did understand, however, that the pulsing screen was asking him to speak.

When we tested the phone call screen, I realized the problem with using a similar animation for a phone in the process of connecting and a microphone ready and waiting for speech. Upon seeing that same type of symbol, my dad expected to be able to talk. The call hadn’t yet been made, though, and he was speaking to no one. In my next iteration I will be modifying that piece of the design and possibly using an ellipsis to indicate that the phone is connecting.

View the interactive prototype at: https://mbgxhp.axshare.com/#c=2

Credit for the iconography I used from The Noun Project:

heat feet and window by Richard Nixon from the Noun Project

Lock by Setyo Ari Wibowo from the Noun Project

Music by Popular from the Noun Project

Microphone by Jivan from the Noun Project

Location by prakruti from the Noun Project

Phone by barjibut from the Noun Project

Settings by Landan Lloyd from the Noun Project

Compass by jeff from the Noun Project

Snowflake by Landan Lloyd from the Noun Project

[hl7mi420]

Digital Dashboard Paper Prototype

For my digital dashboard, used a persona, Kathy, to think about possible pain points in the driving experience.

Kathy

mother of two (5 y/o and 8 y/o)

just bought a new minivan (yellow)

likes to listen to podcasts after dropping off the kids

plays Disney soundtracks or pop radio when they’re in the car

active in the PTA, frequent field trip chaperone

Kathy made me think about a couple specific issues and possible solutions. 

in Kathy’s old vehicle she could probably only play one kind of media at a time. In a new van, she will likely have the option to stream movies and videos for her kids in the backseat while listening to her podcasts on the main audio system. 

as an involved mother, she will likely have social circles of other parents in her community. Would creating a small social media system to allow Kathy to see who’s nearby when she’s driving be useful? 

many AI personas tend to be women, reinforcing the idea that women should be in assistant’s roles and serve others. Would Kathy prefer a male AI?

I nixed number two because I worried it could be too distracting. In my research on similar digital dashboards, I found that many were cluttered and used small icons. A goal of my UI is to break this trend and focus on maximum usability while cutting away distractions.

So I made some sketches.

Physical vs. Digital

For many of my initial sketches, I was preoccupied with how the physical interface must interact with the digital. I worried about what those physical buttons and dials should be, how many were needed, and more.

Eventually, however, I came to the conclusion that the physical interface can’t be in the scope of this project. I adjusted my focus to thinking primarily about the digital UX.

re:The Coat

Sometime sketching random three-dimensional things gets my mind on track. I used to draw a lot of flowers, apparently now it’s half-people.

After roughing out some home screen ideas and focusing in more on the issues I identified, I came to a couple conclusions. I realized that the media playback issue (number one) would be more interesting from a UI standpoint. The idea of a male AI is more of something I find socially and culturally interesting, so while I will include a “Talk to Tom” button on the home screen, him and his features will not be the most prominent part of this interface.

*I may re-incorporate Tom a little more into the digital prototype, but he’s not a priority.

Now that I’d gotten most of my ideas on paper and decided on a direction, I went about creating a more finalized prototype.

Shout out to Kathy on the right!

My prototype attempts to accomplish the goals of my design in several ways. The separate, non-interactive screen at the top displays pertinent information that never gets lost in a screen full of features. While the time display definitely belongs here, I have wavered on what other info to include. Currently playing media (main audio system, probably not backseat media), current route and direction, temperature... In this prototype, I chose to display what’s currently playing and include the other ideas as “cards” on the main interactive screen.

[hl7mi420]

CALapp Paper Prototype User Testing

I narrowed the goals for my college mobile app down to providing information on a few different subjects:

degree programs

curriculum

scholarships

internships

research

Developing an information architecture for this was difficult when I thought of my project as a college website, but upon reframing it as an app my structure became clearer. My design no longer needed to include everything relevant to the college and I had the option to trim the fat and focus only on the most important tasks. This led me to splitting my information into two main sections: DISCOVER and GET INVOLVED.

DISCOVER contains academic information and on the home screen lists “majors, classes, requirements, minors, scholarships.” GET INVOLVED focuses on extracurricular enrichment and covers “research, internships, clubs, events.” I thought this was a straightforward way to show everything this app could do from the home screen while also beginning to clarify an IA.

I also created a landing page for each section, and in doing so, ran into some phrasing troubles. I didn’t want to reuse all three of the same action verbs for each screen, so I subbed out “search” in GET INVOLVED where I might’ve used “find.” The word “search,” however, carries some connotation in web and app design, so I worried it would be seen and misunderstood as something to search the whole app. Because of this, I decided the task I would provide my user would take them through this screen, just to see how they might think of it.

I worried again when I designed the SEARCH screen, because I felt it also needed a search function in addition to the scroll of information I was already adding. I drew on a magnifying glass for a search icon, prepared a final screen where I wanted my user to end up, and began the test.

“Find a research opportunity and apply for it.”

That was the task I provided my user with. For the most part, she sailed through the test and ran into little trouble, which was gratifying of course. She ran into some trouble on the search screen where my paper prototype’s interactivity moved beyond taps, but she quickly figured it out. I’m excited to create a digital prototype and see if that roadblock dissolves or not.

I noticed that she paid no mind at all to my search button, which made made me wonder why that might be. With a few follow-up questions, I got the sense that, while she had noticed it, she may have overlooked it because it seemed ornamental (the page is titled SEARCH, after all). In my revisions I’ll have to make sure the icon is more clearly a button.

It also occurred to me that I should’ve found a way to work returning to the home screen into my task to test whether or not my assumption that users would treat titles in mobile apps the same way as they do on websites was true. I asked my user a couple questions following the test that make me think I’m wrong about this, so I’ll also have to make sure to incorporate some clearer navigation into the UI.

I asked a few more standard follow-up questions, and overall I left the test feeling like I had learned a lot, but also that I have some important changes to make.

[hl7mi420]

Assignment 1 User Testing

I tested my design with three different users and have made decisions about how to revise based on their experiences.

Some feedback was about context and the lack of it within the design. While I explained to my testers what their goal within the app was, they still said they would’ve liked more of an introduction to the app and some visual indication of where they were within it. This point was less critical of my design and more of my testing process. In future prototypes, I will take care to frame the design with a home screen and better indicators to avoid dropping users too suddenly into the interaction.

Much of the feedback of my design was levied on the loading indicators. Some feedback was that it would be better to visually show where data was transferring to and from, although another user said they were her favorite thing about the design (I suspect this had more to do with seeing how the element was represented in a paper prototype than the actual design of it, however). Another bit of feedback was that it should be more exciting and visually intriguing (this tester suggested using a cheetah or something to symbolize speed and agility). I think I need to look carefully at other loading indicators that show the transfer of information between devices as well as elements that are symbolic in exercise and fitness.

Users also pointed out the lack of information displayed on the watch screen. While there was positive feedback about the little running avatar showing how far users were in their workouts, there was a common pain point where testers wanted more information. There were willing to sacrifice the cute and symbolic element for a more useful display, and wanted information like heartrate, calories burned, avg speed, etc. Because there are a large amount of different statistics that could be displayed, I think in further and more in-depth iterations I would want to offer users a way to customize their displays for during their workouts.

One more piece of feedback that tied together the two main design criticisms was that it might be valuable to show the information being transferred back to the phone instead of just a loading indicator. Depending on the route I take with the information display, this might be a very useful idea.

[hl7mi420]

Assignment 1

With this assignment we moved from the simpler single-device designs we have been creating to a prototype that needed to cross between a phone and a smartwatch. Because of that added complexity, I chose to sketch out thumbnails before creating my full size paper prototype. These allowed me to plan a straightforward user flow that I could follow when testing my design.

The first phone screen allows users to plan out a workout, with buttons to add and customize activities. Once finished, users tap the sync button to begin the pre-sync. I chose to keep the design simpler, moving immediately from indeterminate loading screens to something users could interact with instead of including a “sync complete” screen. Once the sync is done, users immediately have the option to begin tracking their workouts on the watch. In keeping with that simplicity, I chose not to spend time organizing a complicated data display on the watch during detached use and instead offered a simple screen to show users how far along in their workout they are. Once they finished, users initiate the post-sync to access their data. The display that appears on the phone post-sync is where information can be accessed and interacted with. My focus was on creating a simple process to take users from the pre-sync, through their detached use, and finally into a post-sync without too much hassle.

[hl7mi420]

Paper Prototyping Exercises