Dream Impact Platform Case Study

8 min readNov 2, 2020

Summary

Client: Dream Impact HK

Role: Principal Designer

Time Period: 1 year

Goal: Design a booking platform for Dream Impact that will create and manage events for current and incoming partners within the organization. In addition to managing partners and invoices created around the booking process.

Problem Scope

In my initial conversations with the PM we broke down the two main issues that we were trying to solve with this whole project:

Give the Dream Impact team access to a more automated process to book events for their partners
Allow the organization’s partners to book as they saw fit, see other events in the community, and have online access to their information

My first thought was to sort out what I did not know given that I was creating a platform for an organization in a completely different country than America for groups of people that I may or may not be familiar with. It is something to be concerned with in any project, but I usually have the option to talk directly to people to clear up issues. This was not the case here, but I was happy to learn that research had already been taking place before I joined on to the project. This would not solve any direct problems but give us room to start while me and the PM created a plan to interview and test people further down the line to create an on-going feedback loop. Further I did not have direct contact with the developers and all thoughts and suggestions were channeled through the PM. This would have been problematic if the PM did not communicate so well the issues and the targets throughout the process.

Research

USER RESEARCH

The PM provided me with Personas and a Journey Map of the partner’s current process to book rooms with the internal team. Seeing as they already had a working operation, determining the breakdown of their audience became more of an exercise in observation than in prediction. The same went for understanding how their partners were creating bookings I just needed a breakdown of what they were currently doing. My job moving forward was to validate and invalidate this information as I learned more from the team and users as we moved forward. In this situation doing extensive interviews for users was not particularly necessary as long as I understood how the internal team went about conducting their research before I arrived in the process. After looking through the Personas and several conversations with the PM around our focus on social entrepreneurs and organizations attempting to make a social impact I had a clear idea of the type of person we were dealing with and what we needed to consider when building out this booking system. Not taking that for granted we would be challenging this throughout the project.

PRODUCT RESEARCH

The focus of this project was the booking system but this system also needed to maintain a working directory for partners, connect the invoices to Quickbooks for the team to manage, manage past and pending bookings for events, and set the base for a community online that did not yet exist. While reading all of those at the same time seems overwhelming (as it most certainly was for me starting off to think about all at the same time) breaking each section into designated timeframes allowed me to do research and design iteratively. Once I broke the platform into sections I wanted to find products that could I could do some form of comparative analysis with. The PM already had in mind a platform that we could learn from WeWork. WeWork had a booking process, a directory, and community aspect that maybe beneficial later. But after looking into WeWork further we were left back in the same position with everything except thoughts on how to proceed with the booking workflow. More specifically how to set the times for a booking in a manner that was flexible.

For the other sections I recognized that all I was attempting to do was organize information into a list and then given that particular section I would need to creation additional functionality to edit information and complete actions. I liked how Dropbox allowed actions inline once you hover allowing for a more clean and flexible interface (should we make adjustments in the future). These became the building blocks for my conceptual sketches that would lay the groundwork for the structure of the booking system.

Design Process

CONCEPTS AND SKETCHES

The dashboard would be the first area that visitors saw once they got to the sight so I wanted to make sure that it functionally provided them with all the information they needed if they simply need to check information or see what was going on. I also needed to consider what the differences would be between the Administrative view of the dashboard and the Partner view of the dashboard seeing as they varied the most amongst all the other sections within the platform itself.

The two sections would vary differently depending on whether you were an Admin (apart of the staff) or a Partner in the community: the Organization Activity/Pending Approvals block and the Community/Summary block. In the Organization Activity/Pending Approvals block I wanted to give priority to all of the actions that both communities needed to do on a regular basis or would care the most about. After determining those creating a small numbered notification system for changes in the given section allowed visitors and staff alike to see the progress on actions they need to take. In particular for Admins I wanted to give them the ability to quickly take action on their daily tasks from an accessible place. In the Community/Summary block Admin views would focus on aggregate information about the Partners while the Partner view would focus on the community events and news, keeping both sides in tune with the community.

Regardless of whether it was a partner or admin, both needed to be able to start the booking process from the Dashboard screen to accommodate the users in efficiently starting the booking process. It was here that I began to go through quite a few iterations to properly begin the booking flow. The booking flow has three main parts:

Set the date(s)
Choose the room(s) with the time
Determine setup of room(s)

What greatly complicated this process was a user’s ability to choose multiple dates and multiple rooms on any of those dates in particular. This essentially opened up an array of possibilities when figuring out what people should do first. Should they choose all the rooms first then the dates? Should they set the event information then everything else? I wanted to narrow it down so after going back to the PM with some questions about the current process and specifically what people tended to lead with telling for her staff I choose to start with the date. Not only would it be a lot easier to approach from a new user’s perspective (because most people have used a date picker before) but you can avoid the error of having people potentially going back and forth through the flow for corrections. Leading with rooms made choosing the date and times for each date more difficult if not done before. It also asked people to know the date before they began to not get into a process with information they may not have yet given how important knowing the date is for booking an event.

Breaking the booking into five steps allowed focus on each particular part of the booking at a time. While I did consider placing this information and a well designed form on a single page I believed that it ended up being a little too much information for someone to have access to a while setting everything up. This of course reduced the flexibility of how people approached filling in the information, but I was fine with this trade off as long as I could test it later to see if flexibility was something to be truly concerned with.

The Booking, Partner, and Invoice section followed very similar patterns being sections of list on each page. For the Admins we wanted to quick actions to the rows that corresponded to normal functions such as approving pending Partners and resolving invoices for Partners. The booking page leads to modals that represent each event allowing Admins and Partners to edit events as needed, while the Partner pages lead to various profiles for each of the partner organizations. The biggest thing to keep in mind on these pages was the ability to edit the information presented in the list as the user saw fit to help people find information as efficiently as possible.

Visual Design

The branding of the company was being done by a third party so while the booking platform didn’t need to follow the branding to a t, it still needed to mesh well with the overall look of the company site. The initial visual elements of the platform were focused around using a brush stroke on the background. The visual designs at the time needed to:

Align with the organization’s current brand direction and feel
Utilize the brush stroke in a recognizable way to the users’

While it did have a unique flair to it, it did not do well compared to what was in the rest of the site, and did not have a clear message and feel to it. We discussed it and brought the question back to the brand designer, which brought back a strong shift to a feel that was more open and inclusive of the audience Dream Impact was attempting to attract.

Conclusions and Considerations

We still have a lot of tweaking to do to improve the booking process and expand on the smaller partner services that are still done manually by the Dream Impact admins. I am not with the team in Hong Kong and we felt it necessary to come up with a plan to engage the partners (users), gather feedback, and scope out what adjustments or enhancements need to be made to create a better booking system.

I learned an immense amount throughout this several month process about working with this team remote. What made this project enjoyable and productive was the open and constant communication that I shared with the team abroad. It seems very cliche to say, but it made clarifying task, making quick adjustments, and challenging both the work and decisions being made much more straightforward. I hope that all my future projects share this level of collaboration.