Startup Ideation, Market Research, Mobile App Design | Entrepreneurial Creativity Course (University of Michigan Innovate Blue)
Mvents was an application that strove to suggest events to University of Michigan students based on their interests, time commitments, and friends so that they could take full advantage of their education.
The problem that Mvents aimed to tackle was a disconnect between the number of amazing events offered by the University of Michigan, and the discoverability of those opportunities on their website, events.umich.edu.
The outcome of the Mvents project was a final presentation of our startup idea to their entire Entrepreneurial Creativity class. While the goal was to release the app to the public, it was never approved to be released on Apple’s App Store.
- My Roles
- Project Manager
- UI/UX Designer
- Team Member #2
- Marketing Strategist
- Market Researcher
- Team Member #3
- Screen Artist
- Market Researcher
- Team Member #4
- iOS App Developer
- Product Strategist
February 2017 – April 2017
We created our first survey to learn more about how students attend Michigan events. We asked demographic questions about gender, affiliation with the university (class standing), where students live, how much free time they have each week, and how involved they are with events on campus. We then asked how often they attend events, what methods they use to learn about Umich events, how well those methods work for them, how they usually attend events (alone or with friends), whether they want to attend more events, and what factors hinder their involvement in campus events. We used a snowball sampling technique by distributing the survey through Facebook and other social media, texting, and asking acquaintances to pass the surveys along. In total, we received 217 responses that provided us with sufficient data to confirm a potential need for the creation of our application, Mvents.
- Students responded that they primarily find events through their email (70%), Facebook (69%), word of mouth (62.5%), while less than 10% said through the Michigan Events Page
- 65.7% of respondents listed not having enough information as a reason why they do not attend events
- 75% of respondents usually attend events with friends, only 14% attend events alone, and 11% do not attend events
- The majority of people said they attend events either 2 times per month (31%) or less than 2 times per month (25%), while 3/4th of the people who said they attend between 2 events per month to 3-5 per week said they want to attend more events
Our solution to the problem of a disconnect between the number of great events provided by the University of Michigan and the number of students attending them is Mvents, a location-based application that utilizes a suggestion system to connect its users with events and experiences that they are guaranteed to enjoy. Mvents first prompt the user to fill out a user profile that asks each user to input or import their interests, time commitments, and friends. The application will then ask the user whether they would like to attend certain events based on their location and what they entered into their profile. For example, if you are interested in sports and specified that you are free on Saturdays, the system would ask you, “Would you like to attend the Michigan Football Game?” When prompted this question, you would also see the number of friends who also showed interest in attending this event, the event details, time, location, description, etc., and if there is a cost associated with the event. These suggestions help relieve any pain caused by information overload and waste time searching for events that the user wants to attend. After attending an event, Mvents will prompt its users to rate their experience at the event and venue. These ratings will help create quality assurance of events and venues. Hence, other users know that they can also expect to have a high-quality experience at a recurring event or event hosted at the same location. Users will also have the possibility of sharing their experiences with their social networks, either internally or externally, on other social media platforms. This way, other users and potential users of Mvents can see all of the high-quality and memorable experiences that other people are having on the platform and can also participate in the life-changing experiences that Mvents can provide.
Business Model Canvas
3) Design Process
For the interface, we worked through some ideas about the user experience, the usability of the application, and the application’s screen flow. Taking the best ideas from our group meetings, I began to design the interface, starting with paper prototypes of the application’s main features, which included the calendar view and event card views. From these paper prototypes, I proceeded to mock-up three interfaces using Adobe Illustrator.
Once I had three digital mock-ups completed, I presented the designs to my sophomore studio class to get feedback on the design concepts. Some of the reactions that I got were that they liked the idea of the calendar opening up to show the events; they liked the design shape in the second interface mock-up and pointed me in the direction of exploring color there in more depth. In addition to commenting on the design, they stated that they like the application concept and wanted to see it made so that they can use it.
Application Flow Chart
Next, I began to map out the entire application at a more detailed level. To do this, I used flow charts to see the interconnectivity of what we wanted to have in the application. Through the flow charts, we were able to see which figures of the application were essential to include in the minimal viable product, and which we could push off for a later version of the application.
Once we figured out how the application was going to work on a fundamental level, and which pages needed to be designed/programmed, we began to design and develop the application. We started to connect the back-end system that our developer had been working on to the front end interface that I had been designing. After designing the screens, and putting what we could into Xcode, we made a Protio.io Prototype to show how our application works.
4) Coding Process
Though our developer had previously made iOS applications, he had never gotten data from an online API (Application Program Interface) in an app. Furthermore, working the date and time in the calendar view was tricky and new for him. Thus before starting to make the application, our developer had to learn how to get data from the Umich Events API, parse the data based on interests and dates and finally store and display the information.
Our developer initially worked with me to understand the layout of the application and how the screens would be connected. We started making the first versions of the screen in Xcode, the platform used to make the iOS applications. Once each screen was in place, Parth connected the buttons, text fields, and other components to the back end programming so that the application would work.
We used the JTApple Calendar, which is an open-source calendar library. Using this library helped us to implement the calendar view. We also used Firebase as our back-end database to store the users’ information and provide a login/signup authentication service. Once our developer learned how to use these services, our prototype’s basic implementation went relatively smoothly without any particular challenging bugs.
5) Promo Video
Making the Video
The video was a way to supplement our product if it was not finished by the end of the class. The company BOX used a video to help pitch their product to potential investors. Their video walked through the primary function of their product with stop motion animation on top of cheerful music. We used this concept as inspiration for our video.
The video’s initial design was to be informative and motivational for the audience to want to use our product. There were many setbacks in the video, one of them being that you must have a special permit to film on campus. Our screen artist, being a film student, suggested that we use stop motion animation for the video, but this was only partially possible due to time. It took lots of thinking to figure out how to make a respectable video for our final presentation. After storyboarding, we finally set on creating a half stop-motion, half informative video. We used Adobe Premiere Pro CC to create the video, and it took us a few days of work to complete.
Final Promo Video
6) Final Takeaways
The end product of this project was a functioning prototype of our application. We planned to submit it to the App Store before our class ended and we went our separate ways, but unfortunately, this never happened. The final prototype featured an exclusive calendar view filled with events tailored to the user’s interests. Users could select days on the calendar and then use swipe functionality to browse the day’s events quickly. They could also make an account to save events to the cloud and access them on any device. Each device could also remember usernames and passwords resulting in a quick auto-login so that users could see their events faster.
What We Learned
The biggest takeaway from this design process was that the content needs to come before the presentation. We had planned to have our application available on the app store before we presented it in class. That did not work out as expected. While we put a lot of time and effort into the project, we were not as far along as we had planned to be by the end of class. There are a lot of factors that contributed to our falling short of our goal. However, even if we had done more work and communicated more effectively, we would not have been able to use our resources as well as possible. If we could have strategized better and prioritized the critical aspects of our minimal viable product instead of spending so much time on the application’s surface-level designs. This way, we could have had an ugly app that worked much sooner. After that point, we could have peaked and developed the interface with knowledge of how it was being used. The interface of our application is beautiful, and the time invested in it was not wasted. However, the utility of that time could have been maximized if we had privatized creating a functioning application before everything else. We were a victim of the time constraint that we were placed under, and if we were able to do the project again, we would have prioritized different parts to finish first.
This process also taught us a lot about communication. At the midpoint of this project, we hit our “first mud.” We were not communicating well, we were not meeting enough, and it was not always clear what everyone’s responsibilities were. As our team became increasingly dysfunctional, it was frustrating to meet with each other because of the unresolved tension. We eventually had an honest conversation about our group norms and discussed what was working and what was not. By bringing our frustrations with each other out into the open, we were able to address them and move forward from them. After that conversation, our communication became significantly better, and we were more focused on achieving our goal. That experience taught us that if something is not working in a group, the best solution is to talk about it.
We also discovered how valuable the space we met in was to the effectiveness of our meetings, during the first month of our project, we at the Fishbowl and huddled around one person’s computer. We discovered that when we met in areas where we could all face each other and look at each other in the eye when we talked, we could communicate our ideas more clearly, and we felt more heard. This made it so that our meetings became more productive.
Another lesson that this course drove home was the value of diversity. Each member of our group came from a different background and had different strengths and interests. This diversity helped us to come up with diverse ideas and help to delegate tasks so that everyone was working on their strengths. Unfortunately, after we took the Gallup strengths finder test, we realized that relationship building skills were not each other’s strong suits, which made it more difficult to resolve tension and find the problems with our group dynamic as they occurred. Despite the issues that presented themselves throughout this project, we were able to power through to create a successful prototype of our application and ended up having an excellent final presentation.