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 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 Researcher and Designer
- Entreprenurial Strategiest
- Team Member #1
- Marketing Strategist
- Market Researcher
- Team Member #2
- Screen Artist
- Market Researcher
- Team Member #3
- 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 medias, text, and by asking acquaintances to pass the surveys along for us. 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 primary 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 prompts the user to fill out a user profile that asks each user to input or import their interests, time commitments, and friend. The application will then ask the user whether or not 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 you have 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 interested in attending this event, the event details, like time, location, description, etc, and if there is a cost associated with the event. These suggestions help to relieve any pain caused by information overload and wasted 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 so other users know that they can also expect to have a high-quality experience at a recurring event or events hosted at the same location. Users will also have the possibility of sharing their experiences with their social networks, either internally on the platform 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 them.
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 main features of the application, 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 mockups 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 help us 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 backend system the 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 help 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 all the screens connected and worked together. Then we started making very basic versions of the screen in Xcode, the platform used to make the iOS applications. Once each screen was in place, Tarth connected the buttons, text fields and other competes 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 backend database to store the users’s information and provide a login/signup authentication service. Once our developer learned how to use these services, the basic implementation of them in our prototype 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. They’re video walked through the main function of their product with stop motion animation on top of cheerful music. We used this concept as inspiration for our video.
The initial design of the video was to be both informative and motivational for the audience to want to use our product. There were many setback in the video, one of them being that in order to film on campus you must have a special permit. Our screen artist, being a film student suggested that we use stop motion animation for the video but due to time this was only partially possible. It took lots ok thinking to figure out how to make a respectable video for our final presentation and 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 user’s interests. Users could select days on the calendar and then use swipe functionality to quickly browse through the day’s events quickly. Users 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 content needs to come before 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 planned. 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 us falling short of our goal. However even if we had done more work and communicated more effectively we still would not have been able to use our resources as well as we could have. If could have strategized better and prioritized the key aspects of our minimal viable product, instead of spending so much time on the surface level designs of the application. 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. At the end of the day we were a victim to 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 was responsible for. 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.
Through this process we also discovered how important 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 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 a good final presentation.