At its core, the Launchpad was meant to serve as the Home page of the Fellowship One product platform. In my tenure as the visual design lead, we released 6 products - however, due to our plan to release a new product for each discrete workflow currently enabled in the Portal product, we knew the number of products could scale drastically. The first issue to solve for was 'How do we display these products in a way that makes sense?' This lead to a number of explorations, and we ultimately landed on three separate views.

The first view was the list view - clean, simple, and to the point. Each product the user had enabled would be displayed as an icon, and any notifications for that specific product would show on the icon. Very minimal for those who like cleaner screens. The second view began to integrate data into the display. Based on the time of day, your location, and the last app you used - or some combination of the three - the size of the icons would vary, in anticipation of what you would need to use next. The final column view offered a preview of the product you were hovering over, and allowed you to view notifications a level up from needing to dive into the product itself. Three different views that each catered to a different type of user.

The next consequence of our product strategy was each product would have a unique URL. As we took a step back, we realized how unwieldy that process would be for users, and we set about solving for a more seamless experience across the product suite.

For inspiration, I looked at the way companies like Microsoft, Google, and Apple handled similar situations. It became apparent that creating a single sign on would be a big step forward in terms of the user experience - and if we were going to suggest an SSO solution, we needed to create value for the user at that point, so that identity management wasn't yet another product piled on top of all the others. Integrating identity management into the Launchpad product itself felt like the right fit for us. It mirrored a similar paradigm that was within the currently existing product, so it wouldn't be too foreign to users, and it improved upon that paradigm by unifying the user's congregant identity with their volunteer/admin identity.

This was a situation unique to the market we were serving - churchgoers tend to be more involved in the administrative/volunteer aspects of their church than a standard member of a similar organization may be, so having two separate logins was an unnecessary friction point. We decided that the system should know who they are, what they do within the context of the church, and grant them access to the products necessary for them to do their job.

The next big thing we wanted to solve for was navigation. Because the majority of workers in a church organization are volunteers, one individual may be serving in a number of different capacities - sometimes over week/months, and sometimes within the same day. We wanted to make sure that the volunteer could quickly switch between being a children's coordinator, to a children's teacher - two different roles, two different products.

Prior to our SSO system, that individual user would have to sign in to each product separately. However, even after implementing SSO, that individual would still have to input a different URL for each product s/he wanted to use. We wanted to enable inter-product navigation from within the product itself. Again, we looked to the usual suspects for inspiration, and we also iterated quite a bit internally on the proper solution. We settled on a 9-dot grid solution, as it felt most familiar to the user.

The last thing we wanted to solve for was discovery and scalability. Given our approach to our product suite - individual products laser focused on one workflow - it was paramount that we enabled easy discovery.

This was so that everyone from volunteers to key decision makers within the organization could see new products we released, and champion a particular product if it solved a specific issue for that user. This was a point of discussion internally - why should every user on the platform be able to see products the organization hasn't purchased?

The idea was to turn the sales funnel on its head. If we empowered individual users to go out and discover a product that would make a big difference to them, and then in turn tell their leadership about the product, our sales team was no longer convincing, but collaborating.The Launchpad product served another purpose - one of fixing public perception about Fellowship One.

For years, the product suite had suffered from lack of dedicated resources. Our customers were passionate about the brand, as Fellowship One was one of the first major players in the Church Management software space. However, even our most ardent supporters were struggling to champion us within their own organizations, as there had simply been no movement for far too long.