Building a large scale functioning app with a great user experience is no easy feat. To do it in 100 days or less is even more challenging. We’re well aware that not all situations are equal, but here’s what it looks like when you have the right pieces to work with.
But first, some prerequisites:
- A sophisticated client who knows what they want.
- A seasoned team that is specialized in their craft. (a designer, two backend developers, one frontend web developer, and two iOS developers.)
- Appoint someone from both the client side and developer side to oversee the project and keep everyone on track.
The Yervana app
Yervana connects adventure-seekers with locals who want to share the activities they love in their own backyard. Guests are able to take part in authentic outdoor experiences tailor-made by local hosts, and hosts are able to monetize what they are passionate about while sharing their favourite activities with like minded people. The features of the app allow a user to browse through activities, select and book the listing they’re interested in, and communicate with the host to coordinate the details. Yervana offers, a safe, secure platform for payment and is managed by a peer to peer review system similar to other shared marketplace apps.
Usually we size our projects in 4 ways. A project can either be small, medium, large, or enterprise level in terms of scale. The project we’re discussing here is that of a large scale app, and was approached with a relatively full team of experienced designers and developers. There was also the complexity of looking at two different user journeys for Yervana (guests and hosts) and each needed to be built out separately.
Day 1 – Day 7 (Discovery Phase)
Before we continue, we need to mention here that the client (Yervana) in this case was extremely prepared. One of the biggest challenges for an agency like ours is working with a client who doesn’t know or is unable to communicate their wants and needs. In our infancy as a company, we’ve had potential clients come in with an idea but no insight into the problems they were trying to solve or proper business goals. From experience, this often led to the client changing their mind about what the product is, often resulting in a bad case of scope creep.
And as you all know, scope creep = added time = over budget.
Luckily for us, team Yervana had a clear vision of what they wanted and what they were hoping to achieve from the very beginning. Before approaching us, they had done a lot of research into the market landscape of the business and had validated the idea with numerous people (all under NDA’s) to better understand if they had a viable idea and how a potential user would want to interact with their product. They also presented us with competitor lists, references of what they wanted, and some preliminary designs of their own. All of this set us up for success early on, and allowed us to move forward much more smoothly with every subsequent step.
After the meeting, our design team conducted additional market research to get some context around the hospitality/travel industry. We looked at which features worked for other apps and which ones didn’t. We then took the ideas that worked, and made our own improvements on them to mitigate some of the issues we found. Evian, our project manager, used a project management tool called Jira to keep everyone on track, and Slack for communication with the team and the client. From there, Felix, our Lead Designer for the Yervana project created an initial mind map in Sketch and drew out some wireframes by hand for the app.
We put the wireframes in front of test users to ensure the flow was logical and intuitive. At the end of day 7 of the discovery phase, we reconvened with the Yervana team to agree on the final set of features. Felix then set out to digitize the wireframes, transitioning the project into the UX phase.
Day 8 – 20 (UX Phase)
From here, we started scripting out the task flows screen by screen, taking into consideration the target persona and the user journey. For the Yervana project, we were working with two distinct user groups: guests and hosts.
Guests: Experience seekers looking for their next adventure.
Hosts: Experience providers looking to share, teach, or guide guests in their field of interest.
We started with the guests’ view as they are arguably the end user and “purchaser” of the app. The main action we had to establish for guests is activity browsing. Not only did we want to make finding activities simple and easy, we also wanted to encourage browsing so that guests would come across activities they weren’t expecting to find.
After clicking on their activity of interest, we looked at what kind of information would be relevant to the guest and what sort of details they would want to see on the screen. In the end we chose to display the fields in a “who what when where” type structure as seen to the left, showing the details in a complete but organized and concise manner.
The next part of the UX considers the most fluid and efficient way to book an activity. There is a fairly standardized process in the industry when it comes to booking systems, so we were able to adapt this process to Yervana quite easily.
Compared to the guest view, the host view of the app was a lot more complex as it is essentially a management tool. First off, hosts have the ability to list or post an activity, which requires the app to ask for all the necessary information that the guests would want to see. Some of the information we asked for from hosts included event name, price, max number of guests, activity type, and dates & time.
We split the listings up into 3 stages: published listings, unpublished listings, and drafts.
Published listings are events that are visible to the public, unpublished listings are previously published listings taken offline but kept available to the creator to republish at any time, and drafts are listings in the process of being created.
The unpublish function is key here since a good chunk of the activities to be listed on Yervana are predicted to be outdoors and seasonal. For example, someone hosting a skiing lesson can unpublish their listing when the slopes close in the summer, and republish it again at the start of winter without having to redo a new listing.
With the bookings, it was a little more simple. The booking feature is a way for hosts to view their upcoming bookings and keep track of their booked activities. They can see the profile of their guests in order to better cater the experience offered.
To allow for greater transparency between hosts and guests, we included a messaging feature allowing two way communication. We also included a review system where users and hosts can rate each other (much like Uber).
After defining the journey of the two types of users, our designer started the technical phase of UX which consisted of digitizing the wireframes into sketchboard and further user testing. At this stage, as you may have noticed, all the wireframes were kept in greyscale so the color doesn’t distract from the true user experience. The point is to have the user testing be focused on the designs of the functions and not the color. That being said, There are certain elements that can only be understood through color. For example, a red dot used to signify an alert or notification. If that dot was in grayscale it’s function would be unclear.
The final version of the digitized wireframes were then sent to the client for review and approval. During this process, we used slack to send team Yervana a PDF version of the wireframes. We then implemented the feedback they provided and sent it back for review. We repeated this process until the client was happy with the UX before moving on to the next step. This enabled the client to communicate feedback in a measurable way.
Day 21 – 34 (UI Phase)
The UI stage is where we apply all the color, making sure to follow the branding guidelines given to us by Yervana. In this case, it was a cool color palette featuring a bold typeface with the purple/violet as the dominant color and a cool pink as a secondary color. Our designer created multiple versions of the UI using a few main screens, and applied different UI treatments to the screens. The versions contain different ideas and elements of the UI, allowing the client to pick and choose between the different features and elements they liked from each one. For example, below are a couple of different options we presented to Yervana on the explore screen:
(UI Samples of the explore screen)
We also presented different versions of the calendar view (one with a calendar picker, and one that is laid out like a physical calendar) and different ways of displaying the activity description.
Yervana preferred the bigger images with more visual pop. They wanted each event to look attractive and appealing with enough screen space do each activity justice. The physical calendar layout was chosen over the calendar picker for visual and functionality reasons. They wanted users to be able to see the dates more clearly. In general the physical view was more easy to use than the picker and the field of vision for dates was larger. For the activity description page, we ended up with a combination of all three samples provided by our designers. We included a segmented control to better organize the information for the guest. We decided on the expanded layout over the truncated layout in order to fully display information without the user needing to navigate to different screens. We ended up taking elements from all the samples provided by our designers, marrying them into the final version below.
After settling on the final screens, our designers started the development handover process. All the UI assets were made available for the development team and all the styles and specs were defined so the development team had all the information they needed to code everything. We used Zeplin (a communication tool for designers and developers) to hand off the designs.
Zeplin is a software that allows for the specification of all the technical details of design assets. For instance, designers can define the size of the elements, number of pixels in the padding, what the exact color codes are, font size, font family, weight etc. We’ve found it to be an extremely invaluable tool to create transparency and communication between design and development.
Day 35 (Development starts)
Before we dive into the development process, we’d like to mention one very important thing.
You could be the best planner in the world and bugs will still come up. Issues will inevitably arise that require revisiting. Planning for this ahead of time and allowing the time for fixing these issues would be your best bet.
Another thing to note is that design is always involved in development phase. We will have to fix any UX problems that come up in development, and constant iterations will be needed before we arrive at a final deliverable product.
We also approached development a little differently for the Yervana app than one would in a normal situation. Because this is a larger sized app, we developed the frontend and backend in parallel in the interest of time.
Day 35 – 50 (Architecture definition)
Phase one of development involves a collaboration between our frontend developer and backend developer. They mapped out all of the screens in the app, and laid out all of the framework necessary for the next phase.
In a normal process, we would develop the API and test it before we start the front end development. However, because we were developing both the frontend and backend in parallel, we populated the frontend with sample/offline data using a tool called Mockaroo which allowed for continuous validation with design.
(Dummy Data on Mockaroo)
The validation of business rules (compliance) also happens here. It’s very important to ensure that we follow all the business & confidentiality guidelines. We set out a list of priorities for building out the rest of the app. Our developers looked at which features were going to be the most time consuming to build. In this case, it was the experience details page. This one page was used almost in every single tab of the app, but showing slightly different data depending on the experience status. The biggest challenge was to keep this page reusable and extendable.
Day 50 – 80 (Feature development)
This is where the magic happens. All the work we did in the previous stages get brought to life in the second phase of development. Our developers are writing a whole lot of code and rejecting a lot of code.
(Look at all the beautiful code on this Bitbucket pull request)
It’s also during this phase that business logic issues start to present themselves. One of the business logic issues we ran into was setting up the event recurrences on the hosts’ view. This is a great example of how an element can seem very straight-forward to include during the concept and design phase, but becomes complex when we try to implement it in development.
To elaborate further, when a calendar event item (let’s call these slots) gets set up by a host, these slots are stored into a database. This all works very well, but let’s think about what happens when a host wants to schedule a recurring slot (an event that occurs once a week or once a month).
If every event slot gets stored in the database, setting up a recurring event without an end date would mean storing an infinite amount of slots into the database. If this sounds physically impossible, it’s because it is. This is exactly what we mean by the term “logic issue”. Our developers had to take this problem, find a suitable solution for it, and implement it into the app (most of the time without the client knowing).
Felipe, our lead developer on Yervana ended up developing a clever solution to the problem. Instead of storing all the event recurrences into the database, the app would only store the first iteration of the event. When a guest is browsing the activity, they can still see all of the recurring slots on the calendar, but these are virtual and get generated on the fly as the guest is browsing. Data storage only happens for the first event, and every event that gets booked thereby solving the perpetuity issue.
We won’t go into the details of every single business logic issue here, but these kinds of issues are quite common during the development phase which is why setting aside time for mitigation and taking it into consideration in the initial project estimation phase is so important. By the end of phase two of development, our engineers were confident we had a version that we could share with the Yervana to get their feedback.
Day 80 – 100 (Finalization)
After we’ve developed all the screens, we did some internal QA, and sent a working version of the app off to the client. At this point, development of the app is pretty much wrapped up. We used Trello, a project management software, to keep track of improvements and issues. We got some pretty positive feedback from the Yervana team on Trello as a tool. The client can raise tickets when they find a bug or want something changed, and we have time set aside to implement these changes.
One thing that every app should do at this point is to register key events such as sign ups, logins, activity booking etc. in order to enable tracking at a later date. Actions like setting up a funnel or structure where user information can be gathered will be extremely valuable for the client. We did this for Yervana during this phase so they have a good understand of user behaviour in the app, and can make informed decisions when it comes to improving the app.
At this point, we’re looking at preparing materials and assets (app descriptions, tags, images, videos etc.) for the app store release. This is an important part of marketing the app. We’ve put so much work and love into designing and developing the app, we want to make sure it’s getting the exposure it deserves!
So there you have it. By day 100, we have a stunning, fully functioning app that’s ready to be put into the hands of the public.
As far as projects go, Yervana was quite a successful one. We were able to mitigate any issues that came up and efficiently deliver high quality work. However, no matter how successful a project is, there should always be debrief session where, as a team, we look at the things that went well and opportunities for improvement. Every project should be treated as a learning experience.
Following the delivery of Yervana, our project manager held an internal retrospective meeting with everyone who was involved in building the app. Below are the top three learnings we got out of this meeting.
1. Spend more time thinking about hidden features
Hidden features are those not included during the design phase, but come up later in development. Although we did allocate time to deal with these issues during the development phase, even more time could’ve been saved if we had spent more time thinking about the business flow in the beginning.
2. Spend more time investigating libraries
Investigate a library upfront. Spend more time at the beginning to have a deep understanding of a framework before applying it. We spent quite a bit of time researching this (which we thought was enough time), but still some features eluded us. Our developers found that a certain form builder was very difficult to customize if we wanted to apply our own UI. In the end, we ended up building our own form from scratch which took a bit of time. Libraries can be very useful and save you a lot of time, but if it’s the wrong one or has certain restrictions in the process of development, it’s time consuming to then go back and change.
3. Control change requests & over inform the client
Clients have great ideas, but we have to tell them the implications that those ideas have on the cost and the timeline of the project. Sometimes it may seem excessive, but keeping your client informed about every little detail will make the entire process more efficient and improve the end product.
Stay posted for updates on how Yervana is performing on the market!