Published on | Prototyping: From UX to Front End — Medium Vivienne Kay

This weekend I spent two hours submitting expenses for a few days worth of travel (ouch!). Most of this pain was the result of UX design decisions.

As I was using the desktop and mobile apps, I imagined the conversations that might have happened before these features were shipped. I take my hat off to the designers who worked on this, because they have done a good job with a complex problem—Workday’s expensing feature needs to account for multi-currency and tax inputs, expense categorization, required fields for both text and images. On top of that, there are a lot of conditional rules to consider (eg. if region x is selected, show applicable tax types). There are also various independent, and co-dependent fields (eg. if you enter a series of itemized values, they must sum to the same number shown in the overview total).

I could go on, but my point is that this is a highly complex design challenge. It’s similar to the juicy, complex problems that we wrestle with at Shopify , and I truly appreciate the tremendous amount of work that has gone into it to get it to this point. Having said that, design is a constantly evolving and adapting beast—feedback and iteration is the name of the game! With this in mind, I took notes at points where I struggled to complete certain tasks using Workday’s apps, and tried to distill the reasons into some key principles that could be applied to any product design.

Mobile app

Help people feel confident in the actions they can, or should, take

Expense vs. Expense Report

The first screen in the Expensing workflow presents a choice: create an expense, or an expense report. It’s a fair question if you understand what the difference is, but I had (and still have) no idea how Workday distinguishes these two concepts— or what the implications are of selecting one over the other. Uh oh!

This is a missed opportunity for helpful content (perhaps with clearer content, illustrative imagery, or links to help documentation etc.). As a user, I could really use some clarification to help me understand which choice is best suited for my current goals (submitting my travel expenses from a recent work trip). While the helper text here is clear about what actions I can take once I’ve selected either option, it does little to help me make the choice I’m currently presented with: “View, create, or continue working on my expenses” is not helpful when compared to “View, create, or continue working on my expense reports.”

The result was that I had to leave the app to search for a help document (Sadly, after a fruitless search, I resorted to taking a wild guess). When asking people to make a choice, be clear about the implications of certain actions over others. People are more likely to leave your app if they aren’t confident about the actions they can, or should, take next.

Highlight required fields before throwing errors and warnings

Automatic warnings in a creation flow 🙁

This one caught me by surprise—every time I created a new expense line item certain fields would auto-populate (thank-you!), but the empty Memo field would consistently throw an error. This meant that angry red alert icon would appear before I even had a chance to input any information, which feels very unfair. When I returned to the overview screen, I got double the angry alert banners which seems overly dramatic for an empty memo field.

There’s also no distinction here between an error or warning (this seems like it should be a warning for a missing field, rather than an error alerting me of an erroneous or broken input). Highlight required fields, giving people a chance to input the information before showing a warning or error message.

Help people resolve errors by providing more context or links to places where corrective actions are possible

Error handling—a frustrating sequence

Since required fields aren’t highlighted in the initial expense report creation form (as mentioned above), I arrived at my report overview screen with an error. “Uh-oh, how have I messed this up already?” At this point, I was unsure what caused the error, so followed the link to “View Error Details.” This took me to a blank page with an error message (that could have fit on the previous page and saved me a couple of clicks navigating around this problem).

Though I now understand what went wrong, I’m left to my own devices to try and fix it. First I tried adding an expense item to edit the fields (ERRRRR… wrong choice!). Next, I started clicking all the buttons on the screen before eventually discovering the Edit Expense Report Details navigation link. This was hidden under the triple-dot overflow menu in the top right corner. I discovered this from the calendar page (which also has an angry alert icon to ensure I haven’t forgotten about the error I’m trying to solve).

Just a note on the emotional impacts of design here, these error messages make this whole experience feel negative. Right off the bat, I am made to feel like I’ve broken something in the form. And then I’m haunted by angry error messages on every page while I navigate through screens to try and identify and resolve the problem. Empathic designs set users up for success. For example, small stylistic changes like styling required fields or prompting for completion before allowing people to proceed helps avoid the need for multiple warnings and error messages. When error messages must appear, provide context on how to resolve the problem, or link to the place where corrective actions can be made. This kind of support can help people achieve their goals faster, which makes your product feel helpful and smooth, rather than frustrating to use.

Consider visual hierarchy when styling actions

The destructive action ‘Delete’ is the most visually enticing button on this entire page. I just want to click it because it’s so vibrantly coloured, positioned centered in the app, and right at the bottom of my workflow—it’s the last thing I see at the end of every form. So enticing! This could cause me to accidentally begin a destructive workflow, or spending time scanning the page for the relatively quiet ‘Done’ action in the top right corner.

Desktop app

Ensure core mobile and desktop workflows are consistent

It’s possible to add itemized expenses in the mobile app, but not in the desktop app

For my meal expenses it made more sense to use the mobile app so I could use the camera to upload photos of the hardcopy receipts. In this wofklow, I was able to add new line items in the Itemization section, and the Remaining count would show me the sum total of those items. After adding my individual items, I would populate the Total at the top of the report (why this isn’t automated is a separate problem).

My receipts for flights and accommodation, however, were more easily accessible on my laptop so I switched to the Workday desktop app for those. But when I tried to add an expense report with multiple line items (Itemized receipts), I was blocked: The desktop workflow requires the Total amount before the individual line items. This is wacky! I had to open a calculator app, crunch the totals on my multiple receipts, enter the total, and then start adding those receipts individually.

The worst part was that I entered the total number incorrectly the first time (I forgot to add the booking fees), so after spending 15 minutes updating all of my individual travel receipts, I was thrown an error and blocked from proceeding. In this moment I was up against a wall—the sum of my items didn’t add up to the total value I had entered, but I couldn’t edit the total. OUCH! So I’d either have to calculate the difference and lie about one of the individual items, (and correct the total and item afterwards), or entirely restart this workflow from scratch. Needless to say, this was really, really, super, extremely frustrating. It’s ok that certain features or workflows differ between a mobile and desktop — as designers ,we should be optimizing for the different constraints and patterns across devices. Having said that, the functionality and expectations for core workflows should stay consistent across devices. The consequence is mismatched expectations about functionality and a frustrating experience that risks breaking the perceived reliability and usefulness of your product.

Use established design patterns for navigation and drop-down links

I did not expect this ‘Actions’ pill to turn into a layered navigation with nested edit actions…

No need to reinvent the wheel or be clever with designs when it comes to basic functionality like navigation or editing actions.

A few other thoughts:

Be consistent about where people can expect to take actions. Some error messages were clickable, others were not. This created a mismatch in expectations and uncertainty about where I could, and couldn’t take resolving actions.
Auto-populate information when you’re certain it will be accurate for most people, most of the time. Otherwise consider a master control or bulk actions. Sometimes the auto-filled fields (like date) was helpful, but most of the time it was wrong every time. This meant that every item I created had incorrect information that required multiple clicks to correct.
Be clear about fields that are co-dependent or connected: Inheritance rules are tricky (information that’s created in one part of a form that populates or is connected to information that’s added in another part of a form). When I first added the Total amount in my report, I had to return and correct it later because I didn’t realize that I should avoid that field and add the items first. Whenever possible, group connected fields together or use content or styling to clarify the implications of that relationship. Even better, surface the fields that people should enter first, before exposing the fields that are dependent on that information.
Keep people inside your app by anticipating the functionality they need: I had to leave the app a few times to go to a calculator.
Label checkboxes clearly: I still have no idea what the ‘personal expense’ checkbox does.

These usability challenges are certainly not unique to any single app or product they reflect the same debates and struggles we face at Shopify, and I assume on many UX teams around the world. I hope the principles and examples here are helpful to fellow designers who are also on this wonderful journey of growing and developing in this craft.

Was this article helpful? Let me know by tapping the green heart 💚 below!

UX Case Study: Forms and workflows (mobile and desktop) was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX Case Study: Forms and workflows (mobile and desktop)

Cool stuff, every week

More Articles