Introduction: Payroll without panic

By reducing errors and guiding users through the payroll process, Paye helps HR managers complete salary payments with more confidence and control.

Pssst…read me!

I created this design for a job application. While working on it, I documented my entire process and decided to convert it into a portfolio piece to show how I think and solve problems.

Getting Started

Before starting, I read through the design brief and then I made a checklist of things I needed to complete within the tight timeline.

This helped me stay on track and ensure that I did not miss key steps in my design process and final submission.

Brief Breakdown and Persona Design

After reading the brief, I highlighted key areas with red underlines. I also did the same with the instructions that came in the e-mail.

Next, I made a summary of everything I had read. The reason for this was to help me remember key points and ensure I was designing to solve the actual problem rather than go off on a tangent. After this, I created a character to represent Ama. Then I separated key data into two parts: Ama’s workflow and how the system works.

While doing this, I also had some thoughts, so I wrote them on stickies. I usually do this because I might forget the idea later or spend too much time dwelling on it. Rather than get stuck, I write it down and focus on the task at hand. An example thought I had was: Should Ama be able to proceed when there are errors?

From the image above, you’ll see the other thoughts I had. I also made note of assumptions such as: “employee details (including bank information) are stored already.” What I meant by this was simply asking myself: what if the employee details are already stored so Ama does not need to enter them manually?

How does payroll work?

I’ve never designed a payroll system before. Since this is my first time, I wanted to understand how things work. While breaking down the brief, I had so many questions running through my mind. Things like: What’s payroll like? How are staff salaries managed? Do they input the data when paying salaries, or does it already exist?

To calm the storm in my head, I read articles and watched YouTube videos on what it’s like to handle payroll.

One thing that got me excited was getting answers to my initial thoughts. For example, I learned that once an employee is onboarded, they are added to the master payroll file. This meant my earlier assumption that employee data already exists was correct. I also learned that most payroll systems have bank integrations, which was something I had thought about earlier. This process gave me a confidence boost because when I started, I felt clueless and unsure.

Ideas and concepts

With research out of the way, I had a better understanding of how payroll works, and I felt more confident in my ideas. One thing I kept at the back of my mind while working was designing the product around Ama, a user making payroll for the first time. From my research, I learned that payroll mistakes can be costly, so I needed to make sure Ama does not proceed if there are errors.

I also wanted to make sure that at every stage of the process, there are checks in place to confirm the data is correct.

Another thought I had was this: let’s say Ama is processing payroll and runs into errors, but she does not have the correct data on hand. Should we cancel the process and make her start again? That might be frustrating. My solution was simple: save the payroll process so the user has enough time to gather the relevant data. I also considered preventing a new payroll process from being started if there is already one with unresolved errors.

While exploring ideas, I had a light bulb moment: since human error happens, maybe there could be an assistant. Something that checks if everything is fine, like Ama’s second eye. It looks out for errors, points them out, and helps guide her.
Immediately, I thought of a chameleon that changes colors. By default, the assistant stays in the corner in a muted grey tone, maybe sleeping and dreaming of snacks. The moment there are errors, it lights up and alerts Ama. If she clicks on it, it tells her what the problem is and suggests fixes.

The only hesitation I had with the assistant idea was that it might feel too playful or unserious for HR.

Mapping out the flow

Research and ideation took more time than I had planned. I only had three days to complete and submit this task, so I had to make a tradeoff. I decided to skip wireframing and move straight into high-fidelity design, but I still needed a clear visual representation of how everything would work. I could either do this as bullet points or a flowchart, and I chose a flowchart since payroll was a new domain for me.

And if you’re wondering, “isn’t a flowchart more time consuming?”, yes, but this was a small design task. Also, working as a game designer taught me how to quickly map out flows, and I naturally think in either flows or bullet points.

Before mapping out the flows, I listed important points from the brief so I wouldn’t design outside the requirements.

I didn’t spend too much time refining the flowchart or overthinking it. I just created something practical to guide the design process. There are definitely parts that could be improved or refined further.

Design Direction

Aside from flowcharts, I also needed to gather visual inspiration to help guide the design. At this stage, I could have reused a template to move faster, but I wanted to challenge myself and see what I could come up with from scratch. The main things on my list were color scheme, font, and dashboard ideas.

Color: I decided to go with vibrant blue because it reflects trust, reliability, and professionalism. Given how strong the color is, my intention was to use it sparingly so I could maintain the clean design direction I was aiming for.

Typography: I needed something clean, modern, and readable. I initially considered Poppins and Montserrat since I am already familiar with them. They are clean and modern, but they didn’t quite feel right for this project. I can’t fully explain why, but my gut said to try something else. While researching fonts suitable for HR and fintech products, I found Manrope, and this one felt right.

Dashboard: I gathered visual references to guide layout and structure. I also wanted to use bento-style layouts, not just for aesthetics, but to break content into clear chunks that are easier to scan.

While exploring design references, I decided to place the navigation bar at the top. My primary reason for this was to reduce visual distraction. The secondary benefit was that it gives more space to the main content area.

Initially I didn’t have plans for the logo as I’m not great at designing logos, but when I experimented with text only logo, it didn’t look right. I researched modern and simple logos, got a few ideas and made mine.

A Note on the screens

Before I present the final design and walk through my decisions, I’d like to highlight something important. The task required designing 3 screens, and while I worked within that scope, I realized that showing only one state per screen wouldn’t fully capture how Paye works.

To address this, I designed an additional state for each screen. This allowed me to better illustrate how Paye handles different scenarios, such as errors and confirmations.

Drum rolls please…

via GIPHY

Company Account

For the company account, I wanted to show two states: selecting an account and creating one.

When Ama starts a new payroll process on Paye, she sees two things: existing company accounts and the option to create one. For this part, I used bento design to structure and separate content. On the left side, we have a card for “Add account” and on the right we have mini cards of existing bank accounts.

If Ama decides she wants to use an existing account, all she has to do is select a card then click on “Start Payroll Process” button.

What if the account doesn’t exist?

Ama can simply add a new account. Initially I had wanted to use a modal or brand new page for this part but I felt it’d be more clicks. My thinking here is, when she clicks “add account”, the state of the page changes and you observe two major things:

1) The “Add Account” card is replaced with a form.
2) The radio buttons on the account card(s) as well as the “Start Payroll Process” button are removed. I designed this so that while creating a new account, Ama doesn’t perform any other action like accidentally starting payroll.

Once bank details are confirmed and saved, we return to the initial view account state where the form is replaced with add account card and buttons are restored.

Review Employees

Once the payroll process starts, we need to review employee data before processing payments.

Building around Ama making payroll for the first time meant that this page needed a few important things: the ability to save the payroll process, prevent Ama from proceeding if there are errors, use visual cues to show what needs attention, and group the table so she can focus on what’s important.

There are three filter tabs at the top: All, Valid and Needs attention. This comes in handy when there’s a lot of data and Ama wants to focus only on entries with issues.

Status is color-coded so it can easily grab Ama’s attention. But status alone isn’t enough, and that’s where the assistant comes in. To give Ama more context, the assistant leaves notes. For example, if an employee has a “⚠️ Needs Attention” status, the assistant might add a note like “bank details missing” to clearly show what the issue is. This guides her to the exact field that needs to be fixed.

The action button is dynamic, meaning its function depends on the employee’s status. If there are no errors, Ama can view the employee and their data. If there is an issue, the button changes from “View” to “Fix”.

In cases where Ama doesn’t have all the required data on hand, the payroll process is saved so she can come back to it instead of starting over. For example, if there are 20 issues and Ama fixes 15, we don’t want her to lose that progress. Saving the process reduces repetitive work and the frustration that comes with starting again.

Until all errors are fixed, the “Initiate Payroll” button remains disabled.

When everything is fixed, the “Initiate Payroll” button is enabled and Ama can proceed to make payroll.

Salary Payments

After initiating payroll, I thought rather than just show payment receipt, why not include payment status like processing, success or failed. That way Ama has a clear picture of each employee’s salary payment state. If someone isn’t getting paid, it needs to be fixed immediately.

Similar to review employees, we use tabs to group payment status: success, processing and failed. That way Ama can focus on specific statuses like failed and check what the issue is. The assistant also comes in to give Ama more information about a failed transaction.

For more details on the transaction, Ama can view the receipt. This shows more information like status, transaction reference, employee name, date and time, company account used and payment method. She can also download the receipt as a PDF. For failed payments, the receipt will show the reason for failure.

With this screen, rather than use a modal or a new page, I figured the best design would be to reduce the table width and put the receipt on the side. The benefit of this is that Ama stays on the same screen while viewing receipts. This reduces back and forth between new pages or modals popping up.

Where’s my assistant?

Earlier on, I mentioned the idea of an assistant giving Ama heads up on errors. We do see the assistant helping in previous sections. It gives notes in tables and tells Ama what the problem is. But that’s just a simple version of it.

During the design phase, I mocked up a character to represent the assistant. I opted for a rounded rectangle because I wanted it to feel friendly.

The concept I had in mind was to position the assistant in the bottom-right corner of the page. When there are no issues, it’s sleeping peacefully. For color, I picked a muted grey so it’s not a distraction to Ama.

When there are errors, it wakes up and the body outline becomes red. This is to catch Ama’s attention. It’s meant to feel like, “hey, over here, we have a problem”. The error state remains until all errors are sorted.

With a time limit of 3 days, I had to omit the character from the final design because I wouldn’t be able to polish it and make the design look better. But I still wanted to include it in my case-study to share what I had in mind.

How Paye Helps

• Designing Paye around a first time user, Ama, means you have a system that’s already made to accommodate and guide new HR managers.
• Paye gives clear feedback through status labels and assistant notes. There’s no guessing what’s wrong.
• Paye reduces fear of making payroll errors for first-time users. Ama can save progress, come back to fix issues, and doesn’t have to restart everything when something goes wrong.
• Paye helps organisations reduce costly payroll mistakes. For the company, this means fewer failed payments, less manual correction, and more confidence that payroll is processed correctly.

Conclusion and Fun Fact

Working on Paye gave me the opportunity to explore an unfamiliar domain. Although challenging at first, I got to learn more about payroll. Seeing that it’s not just a one-step process really gave me more insight into salary payments and error handling.

A fun fact I’d like to share is regarding the name “Paye”. I never mentioned this earlier because I thought it’d be fun to throw it in at the most unexpected place. I always like giving my tasks and mini projects names. For this one, I thought adding an “e” to the word “Pay” sounded cool. I only learned about “Paye” after I had made that decision.

To conclude, designing around Ama, who’s making payroll for the first time, reminded me of why I fell in love with Human-Computer Interaction back in university. The idea of building and solving problems with technology is what drew me to product design.

Thank you

If you made it this far, thank you for reading.