Majestic Project Extended Case Study
A partnership between Intel and Majestic (official MLB uniform partner)
Using a shirt with just 3 sensors: how do you provide an experience that helps coaches and players truly improve a baseball swing?
SwingIQ is a shirt with 3 sensors. 1 in each of the following sections: the hips, shoulders and wrist.
Through placement in those locations, we are able to discern certain mechanics and convey statistics/data to coaches and players.
Rather than simply returning simply one end metric such as speed, SwingIQ allows users to dive deeper into the detailed mechanics and grainular data of their swing. All so that they can repeat what works for a consistently successful swing.
The shirt is designed for the target audience of 13-17 year olds.
A lot of teams collaborated to make this product happen.
- 2 engineering teams, iOS in Santa Clara, California and the Android team in China .
- The UX team, in Portland, Oregon. Tasked with both definining the experience and the Art Direction.
- An algorithms team, deciphering and communicating all of the data that could be returned from the shirt.
- 2 agencies, one to help out with the tablet design, overseen by the UX team. Also, one to handle the marketing and website portion of the product.
- A research team, involved at every step to inform and validate UX decisions made about the product.
- A product team, to ensure the cohesiveness of the product and alignment with the value propositions.
So how did UX get started?
Honestly, this project was handed over to us in a pretty rocky spot. Basically an agency had promised big on this but they weren’t quite delivering on those promises.
So all of the teams collaborating at Intel, had to go in and salvage the pieces leftover to turn it into a realistic, high quality product, worthy of our client and audience’s time.
After getting to know the team as much as possible, we started with research.
July Research Study
Based off of research that had taken place prior to my arrival on the project in July, Regina Geltosky and myself created a number of designs to test among the target audience in Chicago. Which included coaches, players and some parents.
These designs were based both off of the aforementioned research as well as our assumptions. A couple of concepts supported by research were:
- Players/coaches had mentioned wanting to see the data represented through something like an avatar.
- The “Kinetic Chain” or order in which each body part moved, was very important to graphically visualize for users.
- Video would eventually be a powerful component. There needed to be a convenient way of recording, viewing and annotating video.
The primary goal of this study was to observe and figure out the optimal way of representing the data which could come off of the sensors.
Intricacies of Researching With Wireframes
There was a healthy amount of time spent just around what exactly would be the most appropriate way to present these screens and future research stages of designs to users.
For example, what fidelity should the wireframes be? Are certain visual details distracting? Should the designs be in phones?
It’s easy for research participants to get distracted by the smallest detail. We always wanted to avoid any research study bias as well. For this reason, we chose lower fidelity, paper prototypes, to get the pulse of where our user’s minds were at.
What you’re looking at is a sample page of what researchers were provided for this round of user studies. They had detailed information to look at, while the participants just viewed the screens.
Each screen was initially presented to potential users as a possible representation of information coming back from the sensors.
We knew that the hips, shoulder and wrist speeds were the hero data points, but didn’t quite know the hierarchy yet or what would be an appropriate interaction model to access that data.
We wanted to give some thought to represent trends over time as well, considering users had ranked that as a preferential feature.
After Research Results & Recommendations Returned...
It was time to get started with the visuals?
How about time to fire up some UI Kits and start busting out screens?
Maybe time to pass it all over to the dev teams?
No, no and no of course not.
We wanted to take these findings and recommendations to then get sign off from everyone (that’s development, research and the client.) All on the information architecture and features, before designing any visual assets.
*Note on UI Kits: I actually used those to do the initial wireframes faster on a short timeline. I haven’t really used them at all before but that was a nice cheat since I was in a bit of a time crunch.
Influences On the SwingIQ Process
Wireframes & Information Architecture
At this point it was August, we had enough information and recommendations to begin designing the flow of the application. Which miraculously, actually remained the same right through to development with nothing really having to change over time.
This is also about the point where, Ryan Massad came on to the project as the official design lead. Reflecting back on the amount of work there was, there wouldn’t have been any way just 1 person could have done all of this. The desire was to have a simultaneous release across iOS and Android with mobile and tablet form factors included.
Ryan and I collaborated greatly on the remainder of the product–with him handling Android and me handling all of the iOS designs for mobile. We partnered with an external agency, Angry Little Dog to translate designs to tablet.
After boarding out all of the key sections for the 0.3 release of the application, we created a final pass at the application flow, as well as wireframes.
The wireframes included a number of elements for placeholder graphics and information that would ultimately be displayed on screen.
We had a series of decisions to make that would impact future developments of the application. For example we needed to have a way in this version to access a video mode, even though we weren’t designing for it yet. That was solved by having a camera icon on the data view screen that would toggle the user into the video mode of the application.
Initial "Hero" Dashboard Design
Coaches and players had mentioned in July that they would really benefit from some type of 1:1 representation of the swing via some type of avatar.
Accordingly, we designed for a section and placeholder for whatever that visualization may end up as in the future Art Direction. This allowed us to have a plan of attack for when we got there and keep in mind all of the details that would come into play in the future.
We included a number of future-proof design decisions for things we didn’t have concrete knowledge of yet.
For example, at the time we began–the algorithms team wasn’t sure which statistics they’d be able to pull from the shirt with any verifiable accuracy.
So in order to make way for any new findings, we designed a modular system to simply slot in new stats in the scrollable list, as time went on during application development.
For most of the project, I’d say until about 70-80% of the way through designing the product, we didn’t actually have an official Product Manager. So there were a lot of decisions made by the group and a lot of scheduling things to work out.
One of those being, how and when to speak with our client Majestic. We knew it would be integral to guide the client along the process and keep them included at every appropriate step.
It was after wrapping up the wireframes, getting sign off from all of the teams internally and checking with users–that we began to establish a cadence of presenting the work to Majestic.
After guiding Majestic through the flows and getting their feedback. The next step we took was confirming some feature and flow decisions further with users and our research team.
At this point we pretty much had confirmation from our technical teams that implementation so far would be completely possible to execute.
The SwingIQ Brand
Since SwingIQ as a brand was still in its infancy, there wasn’t much of a brand library to pull from to complete a visual language for the application.
What existed were the various logomarks which contained the brand colors and some photography supporting the product.
Using those few items to inform us, we extrapolated them all out to create the full visual voice for the application. Which subsequently would inform the website as well as future marketing materials.
In pulling imagery to begin influencing the Art Direction and ultimately to communicate to the client–I looked at two different tones: a more fun/energetic tone and a very minimal tone. We ended up blending the two together in the final Art Direction.
The colors provided by the team at Majestic for SwingIQ, generally consisted of bright and energetic values. We used those to create a color system in the application, but also added a few others to fill out the language and make it robust enough for us to implement all of the different styles we would need.
Additional Color Choices
In addition to the colors that were provided to us, we added a few softer grays and whites to compliment the current visuals.
It’s worthy of noting that using these lighter colors, though just gray and white values–really went a long way in providing us the necessary versatility in color options.
In particular, the off white, with a very slight, dim yellowish hue, when used throughout the app and contrasting with the bright oranges really started to define the energy of the application.
0.3 "Swing Session" Version 1
Design & Art Direction Version 1 – Animation
In general, animating screens to communicate to team members or stakeholders can be a nice to have for some projects.
In the case of the Swing IQ application, it was pretty necessary. Specifically with the interactions that weren’t exactly standard interaction models such as tapping Swing Details to reveal a list.
The character animation was done using Mixamo Fuse and Cinema4D. However, at this time the general understanding was that the animation could be replicated from information captured by wearing the shirt.
So how do you present this to a client? Not just a client but to the development teams in California and in China, a research team and multiple external agencies.
Old school phone calls and screen sharing with Skype. Coupled with some very organized and descriptive decks.
The UX Design and Art Direction were both very well received after meetings with Majestic. The major piece of feedback was around the avatar which we had our reservations about creating to begin with, however that piece came as a strong recommendation from research.
Majestic wanted us to remove the avatar in favor of another graphic representation of data, perhaps utilizing the SwingIQ colors in the future. This news was fine to us because we weren't too excited about designing the avatar to begin with and the actual design felt pretty derivative of the inspiration.
Before we carried on to the next version, we went through another cycle of revising the data view section as it is the key visual on the data only screen.
Majestic also wanted us to revisit some branding elements throughout the application.
We executed the revisions, alongside the history section which would complete 0.3 designs.
Hero Data View - Visual Exploration
Eventual Final Design
What eventually became the final design had actually been drawn on a whiteboard a few weeks prior to this exploration. (Which I didn’t realize until going back and looking at old photos.)
It was also loosely drawn off to the side in one of the working files.
Semi-Final Data Design
As we approached the final design, after exploring various color options and potentially using all 3, we figured it would be best to just use one color to represent the selected metric, since the colors weren't working well together.
Majestic ultimately sent us back to using the 3 colors since they felt like it represented the brand more, so we dialed the colors a bit so they weren’t so harsh.
Final Hero Data View
0.3 Swing History
Having completed a full version of the application, it was paramount that we proceed with user testing to validate current decisions and inform future iterations. The bulk of the research was carried out by David Kuhns and Christen Mestre Noira. They conducted user interviews and usability testing which were the primary source that informed the UX design down the road.
Throughout the project we refined our process for providing the research team with assets–for example we began primarily with paper prototypes for speed but started using InVision almost exclusively for quick hand off.
It was easiest to use InVision because there were just two of us designing and in fact, when we started using InVision it was just me on the project, so it allowed for designing and producing quick prototypes on the fly afterwards.
Value of Solid Research
The right research can go a long way in terms of comforting stakeholders on decisions made by design teams but also help designers make informed decisions for users.
What I would consider my interactive design alma matter–the agency +Citizen is where I got my start designing in this field. They have a number of thoughts on this particular topic and actually published a well written article while I was working on this project. I adhere pretty closely to this type of process.
They recently published an article talking about the values of Usability Testing, written by the talented Brooke Wendt–which I'd highly recommend and couldn't agree more with.
User Research Studies
Sample Clickable Prototypes
0.5 Video Mode Designs
The last larger feature to design was Video mode, which involved data overlasy, recording and video annotation. The main thing that came out of this section as needing refinement was just how/when to display data on top of the video.
There were actually quite a few iterations from the design team that landed us where we were. The product team was pretty concerned with nailing the value proposition of the product and we were pretty concerned with the experience remaining intuitive.
Below are the results of the full cycle of revisions and user studies for how video mode would end up being developed.
Final Words & Thoughts
One interesting thing that I’ll always point back to this project for, is the amount of wireframes, research, presentation or prototyping work that went into this versus design in a visual or even UX capacity. The reality is, a lot of planning went into this to make it a “measure twice, cut once” type of project.
Further, a lot more of the project was spent navigating team dynamics and strategizing the best ways to communicate to the different teams, individuals and the client.
One thing I gave some thought to recently, just for the sake of exploration, was: if we are thinking very progressively–does this need to be an app at all? For example could all of the UI exist in the calendar? Could this just be a CUI(conversational ui) that just sends the user texts of their updates. Just food for thought, it probably wouldn’t work for this but an interesting exercise nonetheless.
Feel free to contact me for work inquiries: email@example.com