Intro

GIMM Studio is an application that allows a group of faculty and students the opportunity to communicate and collaborate with one another inside of a virtual space. To accomplish the goals of this project, the team found it necessary to have an accompanying website. The website’s functionality includes a place for uploading content into the app, a place to download the app, as well as a place for students to show off what they have done for users outside of the app.

Problem Statement

Expand on current features of the GIMM Studio website to include a small social network and build brand awareness.

Users & Audience

The GIMM Studio team was large and included 3d modelers, software engineers, and designers. The majority of the GIMM Studio project was centered around the VR application which allowed students to collaborate in a digital space. This was also where a majority of the 20 person team worked. In addition to that main team, however, was our small website team.

Gabe Solis: Team Lead & Front End Developer

Jon Kido: Back End Developer

Casey Kawamura: Back End Developer

Kayla Wilson: Lead Designer & Front End Developer

Additionally, I'd like to acknowledge Tyler Schneider's work on the GIMM Studio logo. They weren't on the web team but stepped in to add their logo and help us match the site's color scheme to it.

Scope & Constraints

Timeline

We had roughly 4 months to stand up the site with the whole team being spread across multiple projects so our days could rarely be devoted to this site alone.

Prioritization

Because the site was meant to augment the VR app, anytime something was needed for VR development, we would have to walk away from the site and devote our time to the VR app.

Buy In

Once again, because the VR app was priority, it was difficult creating buy-in to the site from all the people who were invested solely in the VR app.

Process

Low Fidelity Wireframe

I first put together a low-fi wireframe that was based on a requirements gathering. The 2 day turnaround of the wireframe is not something that I find ideal. While we were required to do this because we needed our supervisor to approve us working on it, I had little to no time for research. Ideally, I would have performed a survey and some interviews and used testimonials from those to prove the worth of the site. In reality, the halfway point of the VR project was approaching in days and if we didn't show something to plead our case, we wouldn't have been able to do work on it in the second half of the project. Nonetheless, this wireframe became the base of the website we'd eventually make.

Interactive Prototype 1

Once we got approval, I did a deeper dive and audited what features would be ideal to make. I once again don't think I had the best approach, but in the end we got a lot of useful feedback. From this interactive prototype that I made, we had multiple future users test it and let us know what they thought. From this feedback, there were 5 main concerns.

  • Comment Feature

  • Like Feature

  • Badges Feature

  • Bug Log

  • Privacy Settings

These were concerns of ours because, in the feedback we received, I had some people tell me that a feature was a good idea and then others else tell me that feature was a bad idea. Both sets of reasonings made sense. For example, on the badges feature, one future user said that having badges could make the social aspect of the site toxic and full of ego. Another future user said that badges would encourage her to do more in order to achieve more badges.

Seeing that there was a variation of opinion, I wanted to go deeper. I turned these concerns into a survey and gave it to a group of future users.

Survey Results

We were fortunate enough to receive around 50 responses on the survey, giving the data some statistical significance.

Despite initial concerns that some features might not be a good idea, the majority of people surveyed said they were interested in all of our proposed features. We let this majority guide our decision making and we included all proposed features as well as an additional feature. The additional feature was to have the ability to earn badges for participating. Since the site is meant to encourage students to turn projects into portfolio artifacts, we saw no harm in honoring 'participation'. This feature was suggested during the prototyping of our first wireframe.

Interactive Prototype 2

Using the survey to guide us, we achieved our final design. The badges can be earned in a participatory manner and show up on a user's profile. All posts by a user are up to them whether they want to make it public or private. There is an ability to search for other users and there is a bug log that users can use to register complaints.

While every page took a considerable time for me to design, the hardest and most time-consuming pages were any screens that included a 'post'. I had designed the posts to be a gallery view that showed only a thumbnail image at first. Upon hovering on the thumbnail, the user's info would animate slide out. If the user clicks on the thumbnail, it blurs the background and shows more information about the post.

I made these designs without accounting for the complexity in development.

Final Solution

While a majority of the site was able to be developed (myself contributing to 50% of development) we were hung up on building out the posts as designed. We were unable to create the sliding effect on the single post view and as a result what we were left with didn't look aesthetically pleasing. I take a lot of responsibility for this error because I did not create a fallback design in case the animation didn't work. The entire aesthetic was built on the smooth animations, and those smooth animations were not developed.

Stepping away from that page however, the overall site turned out very close to how I designed and the users were quite pleased with the available features. In the future, I imagine the team that works on the site will add improvements to the gallery view.

Conclusion

Overall and as mentioned above, the site was a success. That being said, my big takeaway is that I should not design in a way where the aesthetic of something hinges on a complex interaction. By default, there should be a good aesthetic that is only complemented by a certain complex interaction, if it works.

Another aspect I would have done differently is to perform research prior to making even the first low-fidelity wireframe. While we were lucky that future users were in line with what we envisioned, this is not always a guarantee.