One Village
(reading time ~ 9 minutes)
In August 2021, a former colleague reached out to me to ask if I would be interested in helping him launch a SaaS start-up.
​
The aim was to build a platform for pre-schools and kindergarten's, initially in the USA, that would allow schools to market to parents in a competitive space, with a professional looking website and with a level of functionality that could differentiate them from the competition.
​
The owner already had a development team but was lacking that spark that comes from UX, a level of consistency in the UI, and some out of the box thinking with regards to ideas.
​
I agreed to come on board, part time (some evenings and weekends), for 6 months to get the company to a point where they had the following in place:
​
-
A design system that would allow the developers to create consistent UI, especially when I was no longer involved
-
The initial release of the platform that would include the following functionality:
-
Ability for a school to self-serve register themselves on the platform​
-
A wizard flow to enable the school to upload their logo, details of their company such as the ages of children they accepted, classes etc...
-
A public facing website for the school based on the information they had entered in the admin pages
-
The ability for parents to schedule a tour of the school from a predefined list of dates and times
-
A messaging inbox that included automated messages and responses (such as when a parent schedules a tour) and the ability for parents to message within the website.
-
This formed the basis of the MVP.
​
I also gave support around architectural direction for the developers based in India, creating database schemas and investigating third party solutions such as messaging plug-ins to help expedite the delivery of the product.
This is part of the schema I created for storing the data of individual classes. It enables the school to create a series of classes, define age groups that relate to each class, assign teachers to classes, set prices and ensure classes don't exceed US State capacity laws.
Discovery approach
With a small team and a focus on delivery, we decided to use Lean UX as a discovery technique. The owner of OneVillage already owned a pre-school with his wife, therefore a lot of knowledge existed. He acted as Product Manager which gave us the triad now of Product, Development and UX.
​
With the knowledge he and his wife had, we could map out the problems we were looking to solve against the desired business outcomes utilising the Lean UX Canvas.
The above template for the Lean UX Canvas is the one we used to map out potential solutions.
​
Some of my first tasks at One Village were to:
​
-
Build out a set of personas - these focused on parent, school owner and school admin roles.
-
Introduce a design system to expedite delivery and incorporate the corporate colour scheme (already defined before I joined)
​
The personas were defined by interviewing the owner's wife who ran the pre-school and a number of other pre-school owners that the couple knew in their local vicinity.
​
With these two tasks complete, we could start to break down the features into value propositions.
We decided we would look to deliver every second sprint. The first sprint would be a design sprint, mapping out the business problem and desired outcome for each value proposition against the canvas including usability testing with a number of local pre-school owners that One Village's owners knew in their social circle. The second sprint would be developing the solutions and releasing the code to our QA or Production environments, with myself supporting the developers. I would also be working on the next value proposition or feature.
​
As I was only working part time, this generally worked very well as the amount of UX work I could output in a single sprint, generally equated to the amount three developers could code and test - although as we continued in the project and the features started to become more complex, I found I was able to create a backlog of work for the development teams.
Features for the initial release
The core value for any school registering with One Village was a fully integrated platform that allowed them to advertise to potential parents, have those parents register on their site, book tours and ultimately become customers.
​
The end point for this would be the school's website. Further down the line we would have a number of different templates that a school could choose from - however, to start with, we began with a single UI and tested this with the owner's pre-school, Dogwood.
​
Our initial release would be to build the ability for a school to put enough information on their home page to advertise their school and allow parents to get in touch. This formed a core value proposition and would allow us to get the product out to market early, all be it not charging, create exposure for the company and start to get beta testers involved. The web site would include information such as:
​
-
Name, logo, hours of operation, address and contact details
-
Age groups
-
Calendars (such as school year, summer or all year round)
-
Further options, such as mornings, afternoons or all day
-
Some pictures
​
As we were building a platform, we also needed to create admin pages, secured behind a sign in feature and also the dynamically created home page.
​
This was broken down into the following propositions:
​
-
Security (sign in, sign out, forgot password, forgot username)
-
Admin pages to enter content
-
Home page output
Sign in and registration
​
As we could not release without a fully secured admin area, this would be our first feature to build out.
​
I'm very much a believer that you don't need to reinvent the wheel. Therefore I created a mood board in Miro of many different sign in formats from different companies, examining the strengths and weaknesses before discussing within the triad of product, development and ending up with the following format.
​
Initial wireframes for the registration page.
An early stylised version of the registration and sign in pages.
Final mobile versions of the sign in and registration page with three slightly different UI treatments.
The design was now simplified to be able to use commonly used sign in methods such as Facebook, Google and Apple.
Home page and admin pages
My next task was to design a home page and then subsequent admin pages to be able to allow the school owner to populate the information on their website. I split this into 3 stories.
​
-
The first was to create a number of different designs for a home page. Ultimately we would provide different templates for schools to pick from and allow a greater level of customisation, however, for the initial release a single design would suffice.
-
Secondly I need to create an admin page that would follow the registration page, allowing the school owner to populate the minimum information on their website that we had deemed would provide value.
-
Lastly, there needed to be a maintenance page that the school owner could access via the sign in pages. This would allow them to edit and maintain the data they had previously entered.
This is the final version of the web site home page.
The site would be responsive. This is the final version of the home page showing on a smaller device such as a phone.
Two alternate designs for the home page
Once we had decided on the look and feel of the website, this could be passed over to the development team to begin to allow the dynamic creation of this page. I then began to work on the admin pages.
​
The initial version of the admin site only had the "Your website" page. This was the minimum we needed to get to market. Below is the design I completed before I left with considerably more functionality included.
Conclusion
Working on One Village was a lot of fun and I learned a lot of new skills such as building out a design system and learning to use Figma (we had previously used Sketch at ADP). Ultimately I used the experience I had gained from creating product at ADP, utilising my technical skills and primarily my UX skills to help form the beginning of a SaaS product that would fill a gap in the market.
​
Whilst my initial agreement was to help out for 6 months, I ended up staying for 7 months before being head hunted to work at Orgvue (and leaving ADP). I felt at this point that I needed to dedicate all my resources to learning the new domain and challenges that ultimately Orgvue would present me with so unfortunately had to end my relationship with One Village.
​
One Village continued for a few months and built out the MVP for Dogwood School (the owner's pre-school) and two other beta clients which continue to this day to utilise the platform. However, funding for the business got very tight and the company made the decision to disband the development team and the project remains paused pending a restart at some point in the future.
​
I created a considerable amount of flows and functionality that ultimately was not coded for One Village before the project was paused. I've included certain screen shots below as an archive.
Archive gallery
My involvement in One Village was always meant to be limited to a 6 month period (although I spent 7 months in total there). Being that we were working with Lean UX, it enabled me to get a considerable amount of design work completed whilst the development team were working on, at times, designs I had created a few months before.
​
Below is a gallery of designs that I had created - many of which have not been coded yet as the project is currently paused.
 admin home pageThis is an example of what the admin home page would look like - a dashboard containing the information the school owner needed for the day along with any messages or calendar appointments. |  gallery desktopA desktop example of the gallery page. School could create events and folders to show activities within their schools. |
|---|---|
 programs desktopThis was a feature that had not been developed when I left. Programs were high level offerings to parents, such as "after school clubs", "summer clubs", "preschool", "kindergarten" etc... Later these would be broken down into classes and a parent could enrol in a class. |  programs adminAn admin area where the school owner could create, edit and delete their programs. They could also create programs ready to be published at a later point in the year to time their advertising. |
 registration templatesThis was a feature that had not been coded by the time I left, however, the concept was to create templates to enable schools to set up programs quicker based on ready made examples they could then configure. |  pricing pageThe pricing page. |
 website pick tour date and time mobileOne of the key features of the website was the ability for parents to self serve and book in for a tour of the school. These are the responsive mobile versions of the page. |  website pick tour date and time desktopOne of the key features of the website was the ability for parents to self serve and book in for a tour of the school. These are the responsive desktop versions of the page. |
 tour confirmationThe tour confirmation page |  admin tour calendarThis functionality allowed the school owner to pick what times of the day, and which days, parents could book in for a tour. |
 admin tour add availabilityWhen adding tour availability, the school owner could schedule one off availability, or reoccurring availability. |  about us desktopThe about us page giving more in depth information about the school. This was all dynamically created in the admin pages. |
 admin messaging inboxA concept that hadn't been created by the time I left was the messaging system. This would consolidate emails, text messages and messages from the website, allowing the school to track conversations with the parents and reply. |