Designing Forms: Following & Breaking Conventions

Before & After: Legacy form redesign

Background

The HR Direct Update form is used to update employee information inclusive of personal info such as name, address and ethnicity as well as current I-9 or residence status. The initial form lived within a SAP legacy framework and was to move to an updated framework. This form is only accessed by HR representatives who are versed in SAP jargon. The form reads from back-end configurations that were not part of the design.

Challenges

The legacy form:

• Does not function consistently and access to the form is sporadic
• Is not responsive to edits being complete (e.g. does not focus on the data being edited)
• Includes features that are no longer updated by HR representatives
• Includes data that is duplicative and irrelevant
• Lacks clarity regarding changes made

Goals

To redesign a form in a new framework that include:

• Necessary features - only the data HR needs/can edit
• A focus on changes being made - The form should focus on the data relevant to what is being edited

Some of the constraints include:

• No scope for backend configuration changes
  • The new form needed to work within the set back-end configurations. This affected my ability to make the form as responsive as I wanted to make it.
• Designing for Pro-users
  • Because the users would be SAP pro users, I designing content consistent with the jargon that they understood. I would never consider using some of this language with a larger audience. This includes being consistent with how the same actions are described in the SAP database.

Forms within forms

The HR Direct form was a form masquerading as many forms. The form as was constituted before the redesign was trying to do too much. A dropdown driven interaction (a dropdown with 15 options) would create tiny changes to the form to show where the user would edit. I say “tiny”, because after playing with the form a few times I was unable to see any updates to the form based on the dropdown selections, nor was there any hint on where to go.

The main flaw was not that the dropdown was driving the form edits (though that was pretty bad), but that there were multiple forms in one. I needed to be able to separate the actions the user would take and organize the content in a way that would make sense for those actions.

Group User Feedback Session

Ideally, I like to meet with users individually and get feedback, however timing did not allow for this. Instead, I got together approximately 5 users to give feedback of the legacy form. I did this on a call using this Q & A format. The feedback from this session helped me:

• Align & prioritize content in a way that would make sense to the users
• Eliminate content that would not be used on the new form
• Test and understanding naming conventions and nomenclature

Designing to focus on relevant fields

Tab Design Format

One of the key requirements of the new form was to focus on relevant fields. As noted, the legacy form has fields and sections visible at all times. I chose to use a tab format to separate each section.

I made sure to apply my research to group content around how users interact with the form. For example, updating personal info like mailing address and name were the most common so that was the section I prioritized from left to right.

Responding to Tab design challenges

Tab designs can have some challenges. I took this into account by requiring users to save each section before going to another tab. Initial designs had the other tabs still visible and a warning message of losing unsaved data if a user clicked away. Later I worked with my development team to suppress any irrelevant tabs when a user was in edit mode. The warning message would only appear if the user chose to cancel the action. With the revised design, users no longer could click to another tab and potentially forget they were in the midst of editing another. 

Breaking Conventions: Icons vs Naming for Pro Users

Use of icons can make sense particularly when they are commonly used icons such as a plus to add or a pencil for edit. But, what if you can add and edit? And what if edit has two different meanings?

In the HR Direct form, a user can “create” and “change” data. This is based on backend configurations that would not change as part of this project.

A user would create when: changing a last name for an employee.

A user would change when: updating a mailing address.

Initially, my design had icons.

Based on the backend configurations and the HR pro user who knew the difference between create and change I opted for keeping consistent naming conventions. My rationale was as follows:

• User base understands SAP and how the current form works
• Icons would cause confusion
  • Placing a plus next to a pencil is just confusing based on UX best practices. If you don’t have content you would ADD (plus). If you have content already you would EDIT (pencil). But you wouldn’t do both --- would you edit data that isn’t there? It could be argued that you could add additional data. However, that would be if you were adding new fields (which is not what this add was communicating)
• Choosing whichever button (icon or named) leads to a “edit” screen that will either require a user to interact with another field to determine what is happening (change or a create). By placing the buttons with the appropriate naming conventions upfront we eliminate an additional validation step. 
  • For example, based on backend configurations that were not being changed (see constraints) a user cannot "Add" Ethnicity. A user can only "Edit" Ethnicity. 

Additional naming conventions on buttons were included to be consistent with the back-end configurations including using my personal SAP favorite “delimit” which means to essentially close a file.

Following Conventions: Single Column Layouts 

The research shows that for completing forms one column layouts are best. This was a different layout than the legacy form, but I chose to go with what was a best practice particularly since the form was now completely different. This was also consistent with the new layout for the other tabs within this form with the exception of names and addresses. An exception that is also considered a best practice.

Lessons Learned

Breaking conventions

As a UX Designer, I am taught to design for the best experience for my user. The majority of the time this means focusing on the everyday user and not the pro-user. This project's only user was the pro-user. Because of this, I ignored my instinct for clearer language and chose to use jargon that would match my user's understanding.

Pushing for best practices based on research

The project owner and developers didn't see why we couldn't do multiple columns. I had done by research and read on a number of forums that one column was best when editing a form. I pushed to implement this based on research.

Accepting incremental changes

The constraint of no backend changes limited my ability to make this form as adaptive and "smart" as I believed it could be. It was tough for me because I wanted to stick to the key requirement of the project of only showing "relevant fields." However, positive incremental changes are still positive as I work on building a design-centered culture within my division.