2019-2020
wireframes, flow maps, workshops, user tests, copy, animation, prototyping
At its most basic level kosciol.app (which translates to church.app) serves as a tool for parishioners to get in touch with their parishes or learn about religious events ran by the parishes or the archdiocese.
Each user can register an account to access a dashboard that enables them to request mass intentions, fill out special baptism, marriage, or funeral forms, search for their deceased relatives, etc. There are two other ways of accessing public information about events, the archdiocese and parish websites (each parish gets its website).
The next part of the system is what we called the priest dashboard, where parish priests were given access to parish management tools. They could create mass schedules, plan carol routes, access the kosciol.app calendar, send and receive messages, manage parish employees, real estate, fixed assets, and cemeteries.
Then at the top level, we had yet another set of tools for the employees of the archdiocese itself whose job was to oversee the subordinate parishes, generate official documents, administer the clergy, all its finances, and real estate.
The project spanned for over two years. Each of the aforementioned parts or levels of the system consisted of many modules. Each module could very well work as an app on its own. The modules I've worked on vary in complexity, and so the approach to working on them differs. I'm going to try and explain how some of the modules in the platform worked, tell you a little bit about the problems I encountered while working on the project and the solutions. This might get a little long, so hold on to your chair and let's go.
Parish priests get the ability to create their parishioners' profiles or authenticate the profiles created by the parishioners themselves. Registered churchgoers could access some of this information.
Figuring out a way to manage all the user profiles and differentiate users with the same names and surnames was one of the biggest issues for us at the time. We had only three requirements regarding the functionality of the user library, namely: the ability to create profiles that only included the name and the surname, the ability for users to migrate between parishes, the ability for priests to create new profiles and search for existing profiles.
We had a couple of options here. The easiest one was to allow every priest in every existing parish to create whatever user profile he wanted with the only requirement being the first and the last name of the parishioner, but that would result in tons of John Does without any additional information ascribed to them. This would quickly result in a very messy and quite useless database, so we knew we had to avoid that at all costs.
Our first idea was to try and convince our external stakeholders to simply mark more profile creation form fields as required to gather enough information to avoid duplicates. We reasoned that if we ask for every user's name, birth date, their parents' names - that should be enough to tell one person from another in 99,9% of all cases. The stakeholder did not like the idea. We needed a database that could store people with only their first and last names.
Since we couldn't figure out a way to avoid profile duplicates or similar profiles that are impossible to tell from one another, we figured that maybe it'd be best if we had a separate profile database for every parish. We'd of course have to convince our external stakeholder that this was a good idea and that there was no other way. I didn't like the idea very much, I thought that the lack of ability for profiles to migrate between parishes and intern-parish profile searchability would greatly diminish the functionality of our platform.
This naturally led me to a solution that sort of combined the two earlier ideas, but in a much less restrictive form, and kept the stakeholder happy. All you need in order to create a user profile is his first and last name, which creates a low-quality profile. These low-quality profiles are only available to parishes that created them (unless the parishioner moved to a different parish, in which case the profile moved with him). Now if you were to supply additional information such as a person's date of birth as well as their parents' names that would create an extended profile, searchable, and available to all parishes.
User profiles can be grouped together creating what we called homesteads. It is customary for Catholics in Poland to receive priest visits in their homes during the period between Christmas and Epiphany (or Three Kings' Day). During such visits, priests collect additional information about their parishioners and that is where homesteads come into play. They serve as repositories for information collected during such visits. Each parish is assigned some territory and, based on that, a number of street addresses. When planning their annual visits, priests have the ability to create carol routes, so that each priest at a parish is assigned a route or a set of routes.
We knew from the beginning that we'd be using maps and geolocation for some of the functionalities of kosciol.app, and so the requirement for this module was so that priests could use it to create carol routes by creating paths, similarly to how it works on Google Maps.
Given the resources available to us at the time, our backend devs estimated the time of implementation of such functionality at around 6 months, provided there weren't any major hiccups. Since we needed the module finished in less than a month, the decision was to settle on something much simpler.
I wanted to at least give parish priests the ability to create carol routes based on street address ranges. So for example by adding North Street to your carol route, you add every homestead that is located in North Street to that route. Since every parish had a strictly defined territory through vectors drawn on the map, my initial idea was to check with our backend if we could gather the addresses from said territory. That information would allow us to automatically create a set of addresses that belonged to every parish.
It turned out that because of financial and technical reasons this wasn't an option. I had figure out a way to design something a little simpler again, so I came up with an alternative solution, that was much easier to implement, but a little more cumbersome to operate for the user. Every parish had to manually add the streets that belonged to its territory first. Only then could they begin creating carol routes. I presented the ability to manually and permanently sort homesteads grouped under one route, but the stakeholders didn't much like the idea, as it'd take too much work. Instead, it was decided to stick with the dynamic sorting and filtering of tables.
The requirement for this module was for priests to be able to schedule masses and for the parishioners to be able to request intentions. There were a couple of additional things that needed to be taken into account. The number of intentions per mass had to be limited to one by default (could be modified and more intention slots could be opened), and we mostly needed the mass scheduler's main function to create intention slots. Considering that parishes tend to display mass schedules on their websites, usually in the form of a stickied WordPress post or something akin to that, I reasoned that if we're already designing a mass scheduler, it'd be nice if we could output this information to a website, and I've managed to convince the stakeholders as well as my colleague that having.
Due to how masses in the Catholic Church work, we needed the ability to add, modify, and delete events to a calendar, usually many at one time, that mostly (but not always) repeated in a certain way indefinitely. Once the events landed in a calendar, we were able to display them wherever we wanted.
So the trick here was to design the module that plays well with the rest of the system, namely the calendar, and also makes sense to the parish priests. The mass scheduler's interface had to be designed using the components already present in our design system, as I wanted to keep the entire platform visually consistent. At the same time, it had to have some similarities with how the majority of some of the existing calendars and task schedulers look and behave.
The earliest wireframes featured a monthly view, where you pick a date and schedule a mass for that particular day. This was no good, as the masses mostly repeated weekly so that each Sunday looked similarly when it comes to mass schedules.
In the next version, I presented our stakeholders with a weekly view. In order to make the view a little less cluttered only the hours where at least one mass was planned during any day of that week would be visible. Scheduling the masses worked like filling out a table form and you had to do that for each week.
Even though they liked the idea and the fact that the scheduler view was similar to working with spreadsheets, something the priests would be very familiar with, they wanted an easier way to schedule masses in bulk instead.
That's how I came up with mass plans that you could attach to the calendar. So the idea here was for priests to still be able to use a weekly view table form that they liked, but with a little twist. There could be many plans, each plan had a specific duration (say, March 1st through June 30th), they could be attached, unattached, as well as reattached to any churches belonging to a parish. On top of that, you could activate or deactivate them. It turned out during user testing that the scheduler was far too complicated. Not to mention it didn't even include intention management, which would make it even more complex. I had to scrap the idea and go back to the drawing board.
Our internal stakeholders opted for using something simple, preferably a table view, so that's what I set out to do. The mass planner allowed to schedule repeating masses and decide on the type of intentions that would be accepted for this particular mass. The planned masses would then be displayed as a long list of table entries. Each entry could be expanded to display a little more detailed information about scheduled intentions.
So to reiterate, you schedule a mass or more. The scheduled masses land in the calendar and are available as intention slots to be filled up by parishioners or priests. The table/list view serves as a way to manage intentions. In order to quickly check the mass schedule for any given month or a week, the priests would use the calendar in a monthly or weekly view, while the parishioners could visit the website belonging to the parish in question or log into the parishioner's dashboard.
My idea when designing the interface for the messaging system was to take cues from webmail interfaces so that it felt familiar. At the same time, I needed to keep its design coherent with the rest of the platform.
After a thorough analysis, I put together a list of messages that could be sent and received inside the system. That allowed me to put them into separate categories based on what part of the system they're sent from. Having done that I was then able to create template messages for the types of messages that our messaging system would support.
Our internal stakeholders wanted the inbox to serve as a place where a parish priest could handle most parish business, where he'd spend most of his time.
The idea was to allow for quick reactions. So for example, if a parishioner filled out a baptism form, it'd appear in the inbox of a parish they belonged to. When a parish priest checked his kosciol.app inbox, he'd see the message and he'd give it an OK to be sent to the list of baptisms, get linked to appropriate user profiles (like child's parents, etc.) if the form was legitimate, or he could reject it if, for instance, it turned out someone was only playing a joke.
I also made it clear to our backend devs at every point that we needed a way for all priests in a given parish to see such a message and be able to react to it. We had types of messages that would be sent to a group of priests based on a parish or any other entity inside the church and all of them had to be able to access it, as long as they belonged to that group.
Aside from the reactions and the group messaging the rest of the functionality was pretty straightforward as it only featured the creation of new messages that could be sent to other users of the platform, replying, archiving, filtering, and searching.
Calendar and agenda views were used all around the platform in all kinds of different scenarios. They were available to anonymous users as well as registered parishioners and priests in one way or the other.
To understand what we needed in a calendar I first needed to find out from our stakeholders what kind of information they'd like to see in the calendar. Once that was clear, I needed to define the number of calendar sources on our platform.
Given that there were many calendar sources and we had a lot of places where we'd need to display calendars with different types of events in them my ideas, that our backend devs liked, was to create a separate calendar in the iCalendar format for every type of event. So, for example, you'd feed the entire mass schedule specific to a single parish to one single iCalendar, and then you'd feed all events created through our CMS specific to a single parish to another iCalendar. So every parish had a few separate iCalendars, each for a separate type of event, that put together created an entire calendar.
Having the events divided into separate iCalendars allowed us to easily build and display calendars in whatever form we needed, as well as enable users to feed their phone calendars with the events from our iCalendars.
The idea behind our very own CMS was to create something easy to use, similar to the already available products such as WordPress, a little more user-friendly, and not limiting for power users. We had a very specific use case in mind, our CMS was mostly going to be used in connection with parish websites. So it had to cover the things that normally take place on those types of websites, namely the normal posts, galleries, and scheduled events that land in the calendar. Most importantly, though, it had to integrate with the rest of the platform.
To achieve the best results and avoid the most issues they should be designed in parallel, but due to time constraints, the parish website was designed a little later than the CMS. In the end, we managed to achieve largely satisfying results and the user tests proved that the initial design was easy to use for those users who worked with CMS systems in the past and easily understandable for those who used a CMS for the first time.
The most important feature was the ability to create new posts. Considering that posts on parish websites often included galleries or referred to some upcoming events. My idea was to make it possible to automatize the process of adding galleries, events, and informing about them through a single new post page. All a priest had to do is move a slider or two to decide whether the new post was going to be a simple news post or a news post and an event as well, for example. In this case, apart from the usual news post content, he'd have to provide a date for the event.
Aside from adding posts, the CMS included a media manager, statistics, and configuration pages. The parish website consisted of a few different modules (like the calendar module in the right sidebar) that could be switched on or off. I also convinced our stakeholders to include several customization options. Each parish could pick a logo from the set we provided or upload their own, we had four color and four font combination options.
I think it's also worth noting that the parish website was one of the places in the platform that called for its mini design system. The general rule of thumb was to avoid using any non-standard components, but whenever it couldn't be avoided, we opted for creating mini design systems to keep the core design system clean of any components that'd only be required in one module.
I was solely responsible for managing and documenting the design systems for the entire platform, as well as performing regular test environment audits to highlight any discrepancies between the design in Figma and our front end devs' implementations.
Thanks to Figma's libraries I was technically capable of updating a lot of screens at once. Despite that, once a design style for the platform had been settled, my job was to try and avoid introducing any drastic changes to any of the components while designing new modules. As you can imagine, global changes could break the design on some screens and with a project this big it was hard to track all the screens that were affected.
Working on a project that takes this long to complete using a cloud-based tool like Figma introduces many unforeseeable issues. Take the change to the font baseline behavior introduced by Figma a while back. Even though the change was generally a positive one, we had to go through all our screens and correct any misbehaving buttons that'd no longer contain the entire text in a single line.
Taking advantage of newly added features takes time as well and with a system this big is often much harder than we initially imagined. It requires a lot of testing and consideration before being put to use. This was the case with the awesome Auto Layout feature. Our team was ecstatic when we first read the changelog, thinking we could finally use it for buttons and button combos, but then it turned out we can't use it right away, as our atomic approach to designing components did not play well with how the Auto Layout worked. Namely, the text elements were rooted in different levels of the component. Thus when we upgraded the parent component, all child components' button labels would revert to the default state. In the end, we had to leave the old button as is and create additional Auto Layout buttons. Only then could we start using the Auto Layout buttons on new screens as well as update all the screens that could make use of the Auto Layout feature by hand to make sure that everything was OK.
The design system required very thorough documentation, but not everything was possible to be efficiently conveyed in words. That's where prototyping came in. I tried using prototypes to explain simple flows and processes, but our front end devs didn't like the idea, so we stuck with flows and regular documentation. In the end, prototypes were only used to explain what some of the animations and interactions are supposed to look like. I would also regularly do reviews to ensure there weren't inconsistencies or other post-implementation issues that were not in the range of what or QAs were testing for.
Aside from the core design system, we kept a few additional mini-design systems for some of the modules that needed special components. This was done to avoid cluttering the main design system with some non-common design solutions and degrading the design system's performance. The parish and archdiocese websites, among others, needed their separate design systems as well.
What made the planning and the designing of the entire system challenging was the fact that we had to deliver it in chunks. So, for example, we were required to finish the calendar module by the end of March 2019. We knew at that point that the calendar module would be communicating with a number of other modules, let's call them A, B, C, and D, but we didn't yet know in what way until those modules were designed, and some of them would have to wait to be designed until, say, November 2019, so once we had the modules A, B, C, and D designed, we could then go back to the calendar module and implement the necessary changes. Of course we'd often run into a situation where modules E and F, affected the functionality of module C, which in turn would necessitate further changes to the calendar.
Building a platform this big with such a high level of interconnectedness required us to be very careful when performing any changes to any of its aspects. One reckless change or addition to the system could render it completely broken and hard to fix. Any careless interference with the functionality of the modules or the design system could result in a catastrophe. It really reminded me of playing a very hard yet satisfying game of Sudoku, as it was a joy to witness it all come to life.