Responsive SaaS App
DoubleGDP was a seed-funded, white-label SaaS startup for African and Latin American property developers to build, grow, and manage planned communities and special economic zones. The software offered a wide range of features with role-based experiences.
As the sole product designer for the company, I took ownership of the entire design process and vision from ideation to validation. I transformed vague use cases into actionable features, and contributed daily to sprints and the roadmap.
During my tenure with the team, I partnered heavily with cross-functional leaders in Engineering and Product to create new modules for Payments, Processes, and Leads (CRM) and to iterate on existing modules for Gate Access, Campaigns, Amenities, Community Hub, Password login and Maps.
Business Directory
Digitizing Paper Processes
When I joined the team, several MVP features had been built, and the UI had no consistency from page to page. So the first order of business was to quickly establish a color strategy using only a primary and secondary color plus 4 alert colors. This strategy had to support any color combination used by our many city admins. I also established UI standards for faster, more consistent builds with reusable components. See the Design System page for more details.
Several cities had complex paper processes that provided little transparency and had difficulty tracking status or progression. I worked with engineering, product and cross-functional team members to convert and refined these existing processes into digital solutions in our platform. These processes fell into two categories: Gate Access and Property Management.
Gate Access
Several cities used a paper "logbook" where the entries and exits were hand written. The MVP for our gate access module was live when I joined the team. My task was to refine the user flows in the module based on user feedback and to add functionality like self-service mounted tablets (kiosks), facial recognition flows, and mobile photo-reliant check-ins for deliveries. Below are a few examples of these solutions and client presentations.
Guest registration proposal with facial recognition
Guard check-in flow for deliveries at the front gate
Self check-in kiosk screens for a mounted tablet at the main gate
Property Management
Two of our largest cities had several paper processes for the various stages of land development consisting of long, threaded email, spreadsheets, and various paper documentation across several departments and locations.
The Head of Product and I conducted user and stakeholder several interviews to understand their current process and what they hoped our system would help them achieve. With the information gathered from these interviews, I documented and analyzed the tasks, created user journeys, defined the permissions needed for each user group and wrote use cases. With my results, I then collaborated with my cross-functional partners on the ideal workflows across cities to make sure any ideas or solutions would work for all our users. In the end, we decided to develop two new modules that we could scale that would cover all use cases: Leads (CRM) and Processes (a task workflow builder).
These modules were later enhanced to include integrations with a payment gateway, Calendly and What's App.
1. LEADS
This module supported the cultivation of new investors and could grow into a light CRM. It was role based with different content and access per user role including the ability for an admin to control teams of other roles. The system triggered notifications, emails and actions based on user detail status, including forms with integrated payments.
Small segment of Admin flow showing how to manage external marketing teams and end users with the Leads module
Leads productivity dashboard showing how milestone goals set by an admin are met over time
2. PROCESSES
This module would support the known use cases for construction, key handover, and resident incident reporting. Long-term product roadmap for this module included utility management (integration with in-unit smart meters), unit leasing, and maintenance requests.
Admin dashboard for all Processes showing stats and providing links for drilling down
Sample of enhanced wireframe client presentation for What’s App integration
Other Initiatives
Community Hub
A feature that utilized an existing discussion board allowing all roles to see and post what’s happening around them. In addition, admins had unique features that included controlling which roles can post, and a post visibility option allowed an admin to post to a group like guards or maintenance.
Screens of the Community Hub feature showing the different role based features for Amins and Resindents
Collaboration user flow diagram for log in with password with team notes (pink).
Login with Password
Initially, the app required an OTP verification on each sign-in. Later we added the ability to sign in with a password in response to user feedback.
Log in flow screens for first time login with OTP and password creation.
Challenges and Outcomes
Few users had access to both mobile and laptop devices
Our users tended to only have access to mobile devices regardless of role so our system features had to be 1:1 across all devices even for high level admin usage and couldn’t show fewer features on smaller screens. This resulted in many of the admin features being tucked away in kabob menus and long scrolling pages which made the paper process conversion a bit more complicated.
Low internet and power reliability
The unreliable service proved impossible for 100% uptime for software and hardware usage including mounted devices like kiosks, webcams, scanners, tablets and phones. We provided backup generators and physical devices including tablets for self-service check-in. It was up to the City’s management team to install and maintain these. Each city accomplished this with varying success.
Diverse needs of cities
We met the cities where they were in their development process. We respected their needs and provided the best digital solutions to achieve their goals. Their unknowns and early paper conversion process required that we utilized the systems that they had in place. Some of these systems were with government agencies and we helped the cities perform at their best under the circumstances.
Low user education levels
This issue came to light after the Gate Access module was live and the guards were interviewed for feedback and the database content was reviewed. They were consistently challenged to spell names correctly or enter other data like license plates or ID numbers accurately.
Shifting political climates
We started on an AI engine for facial recognition but the laws and reining governments in certain countries changed for economic zones during development and this feature was back burnered.
Limited access to smartphones
Some users only had access to “dumbphones” while other users did not have any devices at all. For the dumbphone users we created options in modules for messaging and campaigns for text only. The users with no devices at all were more challenging and we resorted to printing QR codes on paper for them to use to enter the gate. These users were typically site workers from the outer villages and only needed access to the cities while construction was occurring.
Learnings
Reaffirmed the need to document both the “as is” process and the “ideal” process
This helps in early development but also as the product moves along it’s helpful to make sure that it is hitting the target and to verify with the client that the agreed on “ideal”process still serves their goals over time. Several cities took the opportunity during our development to update their process which caused misalignment and we used our documentation to understand where it was happening and and point us to a solution.
It’s ok not to fill the whole page
As a designer presenting to clients, I felt pressure to fill the pages with fake content even though the current topic for discussion was a single selector on and empty page. This was and interesting lesson for me to learn that it’s ok to have a sparse page in very early development and that it is actually better to present it this way instead of filling the page. There were a few things I threw into the design early on just to make a nice presentation that we ended up getting stuck with because the client first experienced the product this way and was reluctant to change the UI. After this happened twice I stopped prettying up the pages and just let them be blank. This really helped in giving us more options later on and avoided the client getting attached to things too early.
Don’t rush to show them progress no matter how tempting it is
One of the things I wish we could do over on the Processes module would be to resist showing the clients progress too early. This rush to show progress compounded the issue above where the client would get attached to our “in progress” just-to-get-it-released-good-enough-for-now-solution. Which on the surface seems like a good thing with less engineering time but as the product matured ended up as a hindrance and resulted in clunky UIs that took 2-3x the effort to correct since the product. If we could have waited a few sprints to show early progress, we could have avoided this and the client’s first experience would have been a good UI solution.