SpaceiShare: Development of a Mobile Application for a Local Sharing-Economy Startup

Gabriel Nylund
11 min readApr 7, 2017

What follows is documentation on my group’s work from start to finish as we attempted to aid local startup “SpaceiShare” expand the reach of their potential business opportunities by developing a mobile platform for their service. Our third major project for RED Academy.

The Opportunity

Continuing my studies at RED Academy under the UX Design program, my third project marks my first occasion of collaborating in a group project with a User Interface (UI) student from RED, as well as our first opportunity to work with a real-world client. In fact, this was the case for all UX students in my class. In addition, the development path of this project unique in comparison to my first and second projects in that it progressed into the “high-fidelity” stage of design — hence the involvement of UI collaboration.

On this project, I had the opportunity to work with Jeff Wasson, Jason Ng, Vivian Ngai, and Kim Marlena from RED Academy. Unlike my previous group’s case, in which we were tasked with a hypothetical scenario in which we had to develop a web platform for a local market neighborhood, I was now doing group work for a real-world startup SpaceiShare (SiS). SiS was founded in 2016 by three entrepreneurs who had the vision of creating a business that facilitated the connection of individuals whom had spare storage space, parking space, and/or small-scale event space, with other individuals that might be in need of it. Basically, an online peer-to-peer marketplace matching service; with only a website to facilitate their service. Since they were only founded last year and still have a burgeoning user base, there’s a world of growth ahead of them. With this knowledge, they sought help from RED (and my group) in developing a mobile app for their platform so that they could further expand on their potential business opportunities.

After discovering whom our project client was to be, we all split off to do some individual, basic, research on our client, focusing solely on their website, before we would reconvene after a set period of time, reporting issues we found with their website and service. Together, we noticed a number of things:

  • Their website lacked clarity on what key demographics are for hosts and renters.
  • While their offerings were interesting ideas (ie. storage space, parking, small-scale event space) without understanding what users want; they may have spread themselves too far too soon.
  • Website is a very basic tool to provide matches but lacks crucial communication features, trust elements, and ease-of-use.

After we reconvened from the comparison of this above-mentioned research, my group-mates and I met with our client to get some insight into who they were and what their needs were. When we had concluded our meeting, Jeff, Jason, Vivian, Kim and myself decided to base our efforts on a few key points:

  • Clarify who SiS’s users are.
  • Better understand their core offerings.
  • Translate their core service into a mobile app through their essential features.
  • Create a more direct path between owners and renters.

Research

Team SpaceiShare (as Viviann, Jeff, Jason, Kim and myself informally referred to ourselves) started with a broad spectrum of domain research. Having remembered my first experiences with AirBnb and Uber, I opted to focus my initial domain research on trust issues within the sharing economy. The rest of my team ended up with similar topics in research of their own. However, we also had data consumer moving & storage habits, consumer intelligence, and trust building, all mostly relating to the sharing economy.

A full view of a Competitive / Comparative analysis I helped put together.
Zoomed in perspective of the top-portions of the C/C analysis displayed immediately above.

In addition to these item we also had a survey tailored to a several clients from SiS’s website, as well as a more generally directed survey towards those familiar with sharing economy concepts, and/or those with direct experience with it. Karen Wang, SpaceiShare co-founder and COO, was kind enough to forward to us some analytics data on their user base which gave my team a good sense of what kind business they were doing as well as what needs they would be likely to have in the future. I didn’t directly write the survey as it appeared to our users, but I did have a strong hand in brainstorming the kinds of questions that would go into it. However, I was the person on-point when it came to collating the general survey data and constructing an affinity diagram from its results (more on that last point later).

A sampling of questions and responses from survey participants.

The results from much of the open-ended questions were as expected. Users showed a significant preoccupation with issues of pricing, security, accessibility, and cleanliness. Of equally strong interests were the responses from the closed-ended questions:

More data from the general user survey.

I discovered in the data shown in the pie-charts above that users were rather divided when they considered whether or not they would be willing to share spaces of their home with strangers, as well as keepings personal belongings of theirs.

A silver-lining in a sea of hesitancy.

Amidst all this came a silver-lining. Price and cleanliness concerns aside for a moment, users were in fact potentially willing to engage service like SpaceiShare, however the data appeared to be suggesting that they wanted certain concerns and reassurances first before they would move forward.

Our initial affinity diagram, in full.
A closer look at some of the questions and survey user results.

All in all, I found these results extremely curious, and did some more comparisons between SiS’s service and that of one of their biggest comparable competitor in sharing economy industry, AirBnB. It had struck my group during this particular comparison that the trust and participation SiS was seeking came from a stronger, clearer, friendlier, and easier to use form of communication, a greater degree of openness of users and their personality, as well as a non-intrusive form of identity verification.

The affinity diagram, further sorted.

After we were done with the work on the affinity diagram that I spearheaded, Jason, Jeff, and myself began work on constructing user flows, the ever-crucial site-map, and eventually sketches for some low-fidelity mockups we would use later to guide the basic arrangement for our final product. Viviann in the meantime, was to design our two main user personas from the data gleaned from our surveys.

“Mandy McPhee” is a user persona focusing on the renter side of the storage space transaction, a freelance travel writer that needs an inexpensive option to store all her things while she travels abroad frequently for work. “Michael Wong” is a newlywed and a new homeowner. While things have gone well for him, this two big changes in his life have made things financially lean for him, and so he’s interested in having a way to supplement some of his income; he’s a persona that best represents a space owner side of the storage space transaction. With our research done and these personas guiding us in their representation of SiS’s typical users, I settled in with my group to begin the planning process for our mobile application.

Planning

Together we began to plan a relatively straightforward system in which information about users was even and balanced throughout the application. Where a visual and communicative tone would be warm, fun, inviting, and yet professional in a design that reflected that a lot of thought had been put into its design. There were no major revisions or shifts in gear in the approach we had taken. Jeff and I spearheaded design of these diagrams below, while I also began initial designs and brainstorming with others how we envisioned the interface to be likely to appear.

Fair left: Sitemap, Middle & Right: User flow for “renter” and “owner” respectively.

Design

Once things hit the design phase for us, things got busy in the group. That is not to say that we weren’t busy before, but our collection of tasks to take on really exploded after this as the necessary components for our app become clearer. The more planning came together, the more I became involved in the design of the low-fidelity diagrams we had begun to put together. In order to work more quickly, we divided up sections of the sitemap between us and began working on low-fi mockups. Examples of some of my work can be seen below.

Samples of low-fidelity mockups I drew up for the project.

After all the low-fidelity mockups were more-or-less completed, we began replicating their concepts in the design program Sketch, where we refined their quality and presentation to a more mid-fidelity level of aesthetic. Below you can see how I took the hand-drawn sketches I had made an upgraded them with my ever-developing Sketch skills.

Designs from the rest of the group were coming along as well. With a lot of these designs we were able to better visualize what we were able to accomplish with our approach to the app, and what we could accomplish with this design. We were also repeatedly discovering along the way that refinements (such as element placement, and extra pages) along the way were needed. It was around this period of time in the semester, during lesson time at RED Academy, that the entire student body had been tasked to engaged in a massive “Design Sprint”, in which we were given a couple of hours approximately to design on the spot an app / service according to a randomly selected set of parameters (this process included students from the UI, Web Development, and Digital Marketing classes). I mention this tangent because it was during all this that I had to confront the fact that maybe I was actually a lot better in my use of Sketch than I had previously given myself credit for. An odd combination of pressure, excitement, adrenaline, and relative lack of consequence (with the design sprint) allowed me to subvert some of my personal insecurities regarding my work.

Design work was really coming along, and I was getting real happy with my mid-fidelity contributions. As was the case with my previous group project, we briefly had a functioning prototype at the mid-fidelity level to ensure general proof of concept and functionality. Where we would differ from that experience with this current project, was that with the planned inclusion of UI design work from Kim, we were also planning for what we call a “High-Fidelity” prototype.

Hi-fidelity mockups, including my improved-upon designs

Prototype

And boy were we proud of them. Kim really did great work for us as well as strove to find ways to include Sis’s colour aesthetics. We were very grateful for the package of design elements that the SiS team had sent us to aid in our development, it went a long way in guiding Kim with her UI work. With both these high-fidelity and mid-fidelity prototypes, we were in the position to begin user-testing of our product before delivering to SiS. Feedback for this phase had been well overall.

  • Users I talked to understood the purpose and functionality of our app.
  • Users had little-to-no issues with navigation, successfully running through our scenarios of renting a storage space, as well as posting a storage space to be rented by others.
  • Some of the screens were a little text-heavy, which we learned could increase the risk of users bailing on the service due to boredom or frustration.
  • There was a strong sense of community communicated in the app.
  • The transaction process proved to be much more efficient compared to the SiS website.
  • Given feedback from a UX professional from outside of RED, we had come to realize that we wanted to be more clear with our copy, during the on-boarding process specifically, what our app was doing. This way users could understand what they were committing to as they worked their way through the sign-up process.

However, overall, feedback was very strong, and we made minor tweaks along the way with each bit of input that we received. Eventually arriving at the final prototype itself.

Summary

As I’ve commonly been telling friends and family that inquire about my time at RED Academy, my general experience here has proven to be particularly challenging and engaging. Much like a long-distance swim. I was personally a little concerned how much the dynamic of a new work group would affect the success of work to be done. And the additional factor of a real-world client to answer to did feel like the stakes of our success were being raised quite a bit.

I was grateful for this opportunity all the same. Grateful towards a client that trusted a bunch of students to do work so personal and important to them, grateful for group-mates that proved to have the most simpatico personalities with mine that I’ve so far encountered with this UX cohort I’m tied with. And grateful that I not only successfully tested and applied skills I’m learning in this school, but showed myself I could be a lore more adept at the tasks required for this sort of work than I previously thought.

--

--