Tyler Technologies is a software company that specializes in designing and developing software for the pubic sector. Their home office is in Plano, TX but two of the major satellite offices are in Maine, where I was hired and worked as a UX designer. The bulk of the UX designers at Tyler work on a UX team that essentially contracts out its services to product development teams as needed. I worked in collaboration with the UX team, but I was hired to work directly within the Payroll and HR development teams for Tyler’s flagship Munis product.
Munis is primarily a data entry application for all areas related to local government including but not limited to finance, HR, payroll, procurement, and revenues. The major selling point of a local government purchasing/using Munis is that it’s one of the only all-inclusive software solutions for local governments. Other software might be better designed or include more functionality for specific areas, but Munis chose to go wide and with moderate depth.
The all inclusive nature of Munis meant that although there was one person or a small group of people purchasing the product, just about every person who worked in the town offices had some interaction with Munis, whether they wanted to or not. Tyler recognized this early in their existence. Although their support network was extensive, they did an incredible job of building an online community and forum for people to ask and answer questions related to the product. Tyler monitored and answered on the forum, but a number of power users emerged as ‘experts’ and voluntarily answered questions to help their fellow public service workers.
This was incredible for the company, for support, and for developing advocates for the product, but it also provided me a unique opportunity to tap into the user-base with surveys and through scheduling user interviews.
Another opportunity unique to the period of time when I joined Tyler was that they were implementing and onboarding Munis in Portland, Maine. I lived in Portland at the time and was less than a five minute walk from Town Hall where the implementation specialists were training people in Munis. Since I am technically on the HR and Payroll development teams, my managers connected with the implementers and allowed me to shadow the implementation process for the payroll team within the City of Portland. I realized it at the time but I was spoiled with the level of access I had to Munis’ user base from a UX perspective.
My managers realized that I needed some time to familiarize myself with the software and poke around as a user before I started-up with my primary project, redesigning the existing employee service portal. Thankfully, there were a number of test, development environments, where I could create an admin account, then create user accounts, to emulate different scenarios and environments, for instance, a new employee going through the onboarding process or an existing employee making their benefit selections, or an existing employee exploring how a life event would affect their total compensation package. Setting up my own accounts gave me some familiarity with how the underlying processes affected the mostly read only interface I’d be working to redesign. It got complex, especially where calc codes and benefit codes started affecting payroll.
I spent a good month exploring, creating, and talking to the developers on my team, many of whom had been working with Tyler for 10+ years and were directly responsible for the underlying architectural framework. This was the period of time Tyler was integrating Munis in Portland, so I spent a couple of days offsite at city hall with the implementation team.
Once my managers and I agreed that I was ready, I started formulating questions for a survey to post on the message boards. I wanted to keep it short, less than a minute to complete, with the majority of questions being demographic and job role related, since my major goal was asking if they were open to having an interview, then grabbing their email at the end of the survey.
I got more than 50 responses in the first 24 hours with more pouring in over the next couple of days and started scheduling times for interviews that day. Thankfully, I’d worked out a script with the research team and finalized it prior to starting the interviews. It was loosely based on the informal guide from Don’t Make Me Think, but I left room for iteration of the script based on how my preliminary set of discussions went.
These set of interviews were unique, because although all of the people I talked too were users, the majority of them were administrators of the system, with some of them the primary administrator who worked with the implementation specialist to set up their current system.
Although the interviews were loosely set up I still had a set of questions I wanted answered, the first of which being what they thought of our current self service offerings. There was a fair degree of customization within our current Self-Service so I wanted to get a better sense of how the organization had it configured and why. My other major interest was determining whether what improvements they would recommend and why.
After the first three interviews I realized that I was on the right track with my script. I also realized that these people needed someone to vent to before they would answer my question. I’d never experienced such frustration from any group of people in any interview setting. The pinnacle was after I was thanking one woman for talking to me, saying that her feedback was valuable for us updating our ESS offerings. She’d come into the interview filled with ire about MUNIS as a whole. She’d called in on our landline and had torn our product apart for the past our but seemed to appreciated that I wasn’t there to be a support representative and got the sense that I wasn’t going to take offence. She was quiet for a few seconds, then said, “When am I going to see the changes? After I’m dead?” I burst out laughing, which got her laughing too. This was an extreme example, but the extent that I had to listen to people complain about our product before and during many of the interviews, gave me additional data that we needed to make significant changes to our product offerings.
I recorded each interview with the participant’s permission of course, but I found it more effective to spend some time immediately after each session and jot my notes down on the Miro-like application Tyler used called StoriesOnBoard. What resulted was a giant note sheet that I quickly started organizing and bucketing into various categories both within, just outside and around ESS and Munis as applications. What resulted was a bucketed list by application and by category of the positives and negatives that interview participants and their cohorts encountered.
The largest amount of complaints centered around general usability of the application, the benefits enrollment process, the pay/tax and direct deposit section, time off, and time entry. Each of these areas, with the exception of general usability, had some level of data-entry and administrator approval component increasing the complexity from the read-only functionally of the rest of the application.
There were other major problems of course, such as one participant describing most of her role in her organization as a password reset expert, where she fielded calls from every department in her local government regarding ESS password resets. Additional customizability both in terms of language employees saw on the application and in terms of adding local/municipality centered graphics/colors was a common ask. Another common ask close to my heart as an experience designer was a direct ask to simplify the information architecture for employees, allowing them to navigate the website without assistance.
One of the benefits of having UX firmly ingrained within the organization was when I finished up my research compilation they brought the payroll and HR development teams together for a presentation, where I went through my findings and fielded questions from the developers and QA people, many of whom had already listened to a few interview recordings. The meeting went well and gave me the opportunity to ask questions of the developers as a group on why they had made specific decisions when they designed the first iteration of ESS.
A few weeks later, my managers collaborated to officially form the ESS redesign team, with Grant as the PO, myself as the designer, and a team of 4 developers to modify the existing architecture in React and redesign ESS entirely.
Before we could get going on the redesign Tyler sent us to meet with the design and development team responsible for designing and developing Tyler’s first design system. It was a learning experience for everyone on our newly formed team. Google had just released its first iteration of Material Design, which was the basis for Tyler’s design system. Material Design strongly recommended using Angular as the front-end development framework which our dev team had never used before and were learning. It was an instructive couple of days where we bonded as a team and took back a slew of homework back to Maine.
The other framework we were instituting that was at Tyler first was Scrum. Up until that time Tyler was a straight waterfall development organization. We were never going to be able to create a complete separation from the waterfall framework the rest of the company was designing and developing against, but Grant was committed to giving it a real shot.
The obvious issue with Scrum at the time was that design wasn’t really considered in the framework. The organization got feedback and integrated it later by saying that design needed to be at least a couple of weeks ahead of development, but it was thrown on as more of an after thought than truly integrating it into the framework. Still, I took the Professional Scrum Master course at Scrum.org to level up my skillset and figure out the best way I could integrate myself into the development process.
I had a head start in a few different ways. I knew about the formation and the project before most of the developers. I also had been studying up on Material design since I arrived at the company since there were rumors that’s the direction we as a design team would be heading. I also had been studying up on ESS as an existing entity, with my own analysis as well as with the user research I’d conducted, so I was far more familiar than the developers at what we were attempting to fix.
This was partly because I was hired for this specific project where the developers I was working with had to be drawn from their specific development teams, HR, Payroll, and the other two developers worked from Tyler’s office in Michigan. This was all pre-covid so none of the developers were used to working far down the line of cubicles from the rest of their development team. Communication became a big hurdle for them where all I had to do was pop down the hall and ask Grant what he thought about the latest slate of designs.
Grant and I had some disagreements as designer and PO do but we generally worked together well, bouncing ideas off of each other and iterating on designs. Our process evolved to working together ideating pages, flows and processes between the two of us, before bringing the screens to the developers to poke holes and ask questions a few weeks before Grant would assign a page or process to a developer to execute. There were a few notable exceptions to this, like when I needed a breakdown of crazy complexity of payroll calc codes. There my boss Jillian set up some time with the two most experienced devs on the Payroll team to break down how everything interlinked and functioned to form a cohesive calculation process, or when I had to follow up on my interviews with a couple of users to test out whether they understood the onboarding process. These instances were few and far between though and I generally felt thankful that my bosses gave me the time to get my research work done before the project officially launched.
Despite the speed of development feeling like a constant issue in our daily, all seemed like it was going well until Grant, our PO announced that he was leaving our team as the PO. It felt like a shock to all of us but the pressure of being in a leadership role, constantly pushing our developers to stay on the timeline felt like too much pressure so effective immediately he was stepping down and our new PO Julie from the Payroll Dev team, just a few cubicles down from me would be taking over.
She and I had some early back and forth on some design decisions but we quickly struck up a really good connection. She was willing to give me more pointed feedback than Grant was which resulted in better, more thought out designs.
As ESS was rebranded to the Employee Service Portal ESP I got into and started attending grad school for Human Factors in Information design, I met my future wife, and I started attending more UX events in the area. It was at one of these events that I learned about a posting for a Senior UX Design position at UNUM insurance, just down the street. The position offered a higher salary and something I craved more, which were mentors who had been in the industry for 10+ years. I interviewed and got the job leaving my first position in the industry and the reason I moved to Maine.
Analyzing my work at Tyler is almost more a life retrospective than a career retrospective. It was my first job after living and working in Saudi as a swim instructor. I moved to Orlando post-Saudi, struggled with the lackluster tech scene down there, and felt incredibly lucky to get a position from the random job fair I attended in Maine.
The opportunity from a professional standpoint was incredible too, with Tyler’s active user-base that was itching to hop on user interview calls, and with managers that were excited to give me an intro-period to play in the development sandbox and do a thorough heuristic analysis of the platform I’d be improving. It was a great first design job, but I was excited to seek an increase in the complexity of design work the job at UNUM could bring.
