Reduce “After-Market Fixes” with the Right Questions Before Coding

I recently worked on a project with a very short runway before launch. After the successful launch, I reflected on various bugs I see repeatedly, on this and other projects. This is especially true when designs are created just ahead, or even in the middle, of development. From that reflection, here’s a list of items to consider when designing a new feature or application. I came up with these discussing this with Phil Kirkham. Asking these questions before any code is written can reduce “friction” in the UI. It can also help reduce churn as these minor after-market fixes are made once the product is in production, where the cost to fix in dollars and user perception is so much higher.

Who’s There? (Empty State Behavior)

Whether you are writing a transactional database, a reservation system, or a document storage system, for most of the user’s interaction, there’s something to see. But what should the user experience be the first time they log in, when there isn’t any data? What does the empty state look like, and how do you help the user do whatever to use the app or feature and never look back…?

Dates: My Place or Yours? (Date References)

Date and date calculations are so problematic, this is an area I pay special attention to during testing. I usually start by changing my location and time zone on whatever device I’m testing so it’s not the same as wherever the database is located. I’ll also switch to using 24-hour time format. If the app has global users, I may choose another country, which will also affect the date display. That is DD/MM instead of MM/DD or even a different calendar year. Doing these things helps me identify what time zone data is displayed in. It also helps identify places where date calculations are making incorrect assumptions.

Where an app allows a “Start” and “End” date, as well as editing those values, I set them, making sure they follow any rules correctly and then edit the “End” date BEFORE I change the “Start” date. For example, if there is a window of how far in advance I can book something, I verify that when I set up the date range. When I edit the “End” date first, and then edit the “Start” date, are the rules still correctly applied or do I see dates AFTER the “End” date?

A to B with a Quick Stop at Z (Sort Order)

When you are displaying a list of information anywhere in the UI, ask what the sort order of the data should be, or look to see if the same data is already displayed elsewhere in the UI. Displaying a list in consistent order, with some intuitive logic behind the ordering, reduces the cognitive load on the user, making it more efficient to predict and use.

The Energizer Bunny: It just keeps going and going… (Character Limits)

Fields have defined real estate on a screen, but the field may allow more characters than are shown. Showing a character limit prevents the user from running out of space suddenly or finding that only half their message is shown when they craft the perfectly-worded message in another tool (Microsoft Word, for example) and then paste it into the field.

Additionally, no limits mean the user can copy and paste “War and Peace” or “Moby Dick” into the field, filling up a database quicker than planned. (Side note: Pasting text into a field may bypass validation, so check that too.)

The Table Cloth Trick (Referencing Something Deleted)

You know the trick where the magician pulls the table cloth away so fast that nothing else changes? They never offer to “undo” that trick by putting the table cloth back on the same way they removed it.

The same is true when the user deletes something and then tries to reference the deleted object/entity again. For example, you add push notifications that deep link to another area of the app. But, the user can delete or move whatever you are linking to, so that the deep link no longer has any place to direct to. Have you handled that?

Who’s on First? (aka Starting with 0)

If you have an array of items, computers like to store the first item at zero. But, as a human, you expect the first item to be 1. If you are coding in a rush or when you are tired, you could end up writing code where you delete the first item in a list and delete the item from array[1] and not 0. Or worse, you try to delete the last item and delete array[10], and then error out as the array only goes [0-9].

When testing, try deleting the first and last items in a list and test that deleting an item actually deletes the item you wanted and not one above/below it.

%^&* (Encapsulation)

When creating a field, it is easy to make assumptions about the data and data source that may not be valid. Encapsulating the data input or received helps ensure things don’t break when saving data or when using the data later.

For example, you are creating a form including mailing address so you think “Name” accepts alpha characters only and the “Zip Code” only accepts numbers… Unless your name is “O’Shay” or “Hamilton-Adams.” Or you are mailing a package from Detroit, MI USA to Windsor, Ontario, Canada, with the zip code “N8N 1A1.”

A Picture is Worth 1,000 Bugs… (Compression, Cropping,  etc.)

At some point, you’ll likely build an app that allows the user to upload a file. Maybe that’s a PDF or document, a video, or a text file. Ask questions about the supported file types, compression methods, and the file size limit. (Definitely push for a reasonable maximum, or your database will bloat). Will the image be centered or aligned, and are there rules for the incoming image? (For example, “It has to be square with the max dimension of X.”)? Look for places this is already done in an existing app so the experience is consistent for the user.

Rounding (Math Precision)

Simple math seems easy. Then throw in some varying precision lengths, such as calculating fees based on percentages, then some division, such as dividing by months or number of days in the month which you need to round, and then precision really starts to matter. Pay attention to boundary edges such as fee brackets that will charge a different amount based on a whole number. When you are testing, try to enter additional decimal places. Or, try pasting a longer value since developers sometimes forget validation on pasted rather than entered values. Rounding errors can cause differences in time calculations (differences in clocks).

Round Peg + Square Hole (Frontend/Backend Validation Mismatches)

If you aren’t doing full-stack development, consistency between what the frontend and backend expect can definitely cause errors. Say the frontend defines something as required, while the backend has it as optional. Then, the first time it comes back empty, the front end will have an error. Inversely, if the frontend passes data that fails backend validation, the user could lose time, effort, and maybe a great opportunity (think sale prices!) because the front end didn’t keep the data in the form until the success came back. Discuss what is required and any other assumptions across teams to prevent errors for the user.

These are some things I ask about when reviewing designs and story acceptance criteria. What other common “gotchas!” would you also recommend asking about to reduce after-market fixes?