Feature Overview

Federal employees are required to fill out documents for various reasons such as NDA's, verification of task completion and other use cases. The new federal requirements were moving to having an annotation process between employees and HR agents when form fields were filled out improperly by the employee. There were also stringent accessibility requirements to meet around this process.

The UX issues

• For Employees:
• Time that was being wasted by form rejections and refilling out of forms
• Many pages to fill out per each PDF form and no way to save progress
• Hard to understand which forms are mandatory
• Hard to understand the due dates

• For HR Agents:
• No field level change/annotation process for PDF in our current software
• Extra layers of UI (annotations) make accessibility challenging
• The journeys can loop over and again
• No easy to use UI that meets all ServiceNow standards (common components)

The business problems

• The federal government often still deals in paper forms and needs PDF modernization
• Low HR sales due to some federal agencies missing key annotation features

First Steps

The research had already been done by the time I joined the project. I was sent to our India branch with our key HR Sr. director of PM's to work out the feature requirements with the research in mind.

Creating flow diagrams and wireframes

Our document templates already existed. We broke down the flows and created a simple journey map, so we could present to leadership where the issues existed and how we would work new feature concepts into it.

Creating high fidelity mockups and prototype

We had a feature that we could use as a base, but we had to design for all the note taking capabilities and back and forth interactions until final approval.

Core solutions

HR Agent:

Existing: A signed document is gathered from an employee in PDF format and reviewed. Rejected, or accepted with general comments.

New: Ability for the HR Agent to review a filled out document from an employee. The HR Agent then approves the document, or leaves notes on specific fields and sends back to employee's portal for field level corrections.

Employee:

Existing: Ability for the employee to fill out documents and sign them in the employee portal. New portion: If the HR Agent reviewed these and they needed changes.

New: Ability for the employee to view HR Agent comments, understand where their mistakes were and check off the fields they have corrected. Then, send changes back to HR Agent.

Key takeaways

This was one of the most complex features I have ever worked on. Government accessibility requirements are rigid and PDF notations and signing are very complex in this regard. One of my favorite sub-features we created was the accessibility shortcut menu. It brings me true happiness when my designs can be used by anyone, even if complex in nature.

The UX issues

The task for me was to redesign this feature, top-to-bottom. The ServiceNow HR team created a powerful internal campaign engine for internal employee communications, but it took 20 different screens and 8 different modules to create a campaign and it was all a disconnected process.

The business problems

• Low adoption due to complexity
• Key customers complaining about the confusing process
• Highly sought after feature which is hard to use
• Key HR initiative is losing momentum

First Steps

There was already extensive PM research done by the time I was assigned to be the designer on the project. I took all the documentation and poured over it. After getting a good feel for the issues at hand and what had transpired previously, we had a few design sprints and many brain-storm sessions.

I then consolidated the efforts and created a user journey diagram pinpointing where the issues were in overall architecture and usability.

Creating high fidelity mockups and prototype

After the wireframing phase was approved, I put together the intro screens and built out a prototype of what the team had agreed upon.

Validation testing

I try and use a pretty stringent testing method so I can synthesize the results without bias or false positives. I put together a timed script, tested the users and synthesized the results. After this I put together a deck to present the results to upper management for final sign-off.

Final Designs

We took in the feedback that the validation testing gave us and incorporated what was feasible into the designs. Afterwards we presented them to the design review board, and they were approved for development.

Delivery to the development team

I took the new designs and broke them down into full red line annotations. I also explained which components to use and how they interact together.

Development review process

We conduct a stringent review process once the developers have completed a project. A developer instance is provided to design and we review it stringently to make sure it matches the approved design.

Key takeaways

I was proud to release this product and work on it for 2 subsequent software releases. When we did follow up validation, the users gushed about the vast improvement in architecture, usability and the ability to preview all the campaign content.

An overview of the Default Program Calendar

The default program represents a single marketing initiative. You can think of it as a container with all the stuff that you need to make the program work - these are called local assets and include landing pages, email, smart campaigns (automation), and more. In each Default Program lives a Scheduling Calendar. It shows you when all of your pertinent calendared events take place.

The problems

From The Business Perspective

• Low adoption
• Users don't know it exists
• Solution imperative from stakeholders due to past investments
• Internal and external confusion between the global calendar and the default program calendar
• Poor perception from customers of the feature

From The UI/UX Perspective

The numbers pertain to the marked up image below:

1. A big conceptual issue was that a mistake was made to blend an agenda view and a month view together which kills horizontal space and becomes confusing to users
2. The month arrows point up and down, which makes no sense for a standard calendar and the arrow next to the date opens a date picker
3. The inline creation process forces a name before a type and then one can't distinguish what some of the types mean... Single click to create is jarring
4. Marketo asset names are typically long, which don't fit in a small area
5. Global calendar overlays have no distinguishing characteristics
6. All entry types need to be able to be distinguished better
7. User research determined that marketing professionals were not using a 3 week view at all
8. Global views, a complex theory, are made even more complex with a buried and non-intuitive UI

First Steps

This was a very open ended project at the onset with no product manager attached to it. It was up to me to do some initial research and conceptualize some possible solutions while the organization freed up one of it's product managers. Before I started down the user research route I wanted to learn the internal history of this feature. I discussed it with anyone who had laid hands on it from the director of UX, developers, PM's, to the VP of product. After which, I was able to have a high level idea about where the calendar stood within the organization.

During that time I was doing a lot of research on calendering systems and especially marketing calenders. I started doing research all over the web and collecting my findings on Pintrist. Here is a screen shot from my board:

User Testing

We had been working on reorganizing the UX department for a while and instituting new processes. One of them was user research. We had a new system in place and it was wonderful to be able to test it out with this project. Our findings backed up what most OS us already knew, but we ran into a new major issue:

• Marketers don't typically plan their work on a calendar

Many of the users we talked to liked to take a more holistic group approach, which looks something like the image below. It could be in a binder, or presented in other ways, but onset planning with a calendar just wasn't popular.

The calendar was being used for some of our larger enterprise clients for pure tracking of activity, so it was out of the question to disrupt it at this time. Also, there was too much other work happening with a complete redesign. After we presented our findings we came up with a direction.

The Strategy

Fix the UI/UX for the Default Program Calendar, which we would parody with the Global Calendar in a future sprint. In the next sprint after that conceive a true marketing planner that overlays onto the existing calendar.

After we had taken care of the direction we had to address another issue:

Designing with a new UI system in parallel

At the same time as I was designing this, our team was re-architecting the UI, creating a whole new design system and also a pattern library. We decided to forgo wireframes for this project so we could focus on fine tuning the UI and architecture. I knew this was going to be tedious, but it paid off in the long run, defining many of the styles and patterns that we would use later.

Final Designs

We went though many variations, sprints and changes. Here is a look at the final UI polish and UX fixes.

How we addressed the issues

1) Separate the agenda view and the month view into independent view, also adding day, week and modal

The design outcome was to create a new day view and all time agenda views, which are more typical to calendars. We also created a week view and a modal view that let users stay in context when working in week or month view. The view selection is prominent; Directly under the header date.

We also decided to remove the three week view as it wasn't being used.

2) Fixing issues in the top level navigation

Having a date picker was essentially having a calendar in a calendar, which made little sense. Also, the up and down arrows were confusing users. We simplified the interactions and made them appropriate to each view.

3) Rethinking the creation process

After user testing we determined that the creation process within the calendar itself was almost never used. Typically a user would create by duplicating from a template within the program and they would automatically populate in the calendar. The last attempt was to robust of an operation in an inline list, so we decided to move all creation into a modal, so that we could simplify the information for the users. We also let the user decide if they want to edit the entry further, or stay in context to where they were.

4) Solving the issue of long names in a small container

After much brainstorming and design exercises, we came up with multiple solutions for this issue. The best solution for this is the agenda view. The names are clear and can be read completely. The user can also drag the column over to the right to afford even more space if needed. Another creative solution we came up with was to hide certain days and collapse the navigation tree, which affords more horizontal space in the week and month views. Lastly if a name is hovered over on week or day then the user will see a tool tip with the full name and details.

5) Simplifying the filtering process and visualization.

The first thing we did was move the filter controls to the top of the UI for prominence.

Previously, the user used the same panel to filter global views with entry types, which was an extremely confusing mental model, so we split up the filter by asset type and global filters into two panels.

The default is to only displayed local entries to that program. If a user wants to filter in entries from the global calendar, then The global calendar filters are used to display entries from the users whole app instance. By inserting a global icon in front of the entry the user can now quickly identify a global entry.

6) Give the user the proper visual guidance as to what the icons and colors stand for.

We needed to visualize what all of the icons and colors meant. We didn't have enough room in the UI to create a good legend system, so we decided to bundle it into the viewing by type panel. We also made sure to add the icon in the global filters panel label so that the users would associate it when viewing it in the calendar.

Delivery to dev

The process of delivery to dev is to mark up the design with thoughtful direction and red lines thatdictate styles, padding, sizes, etc. To coincide with this, any new animations and interactions that have been designed are animated with Principle and output to Gif, then uploaded to InVision where dev, design and product management can converse about them. Lastly, all sprints are run through JIRA to keep track of all activity.

User testing validation

We tested the new designs with the same user pool to be able to validate the new designs. We received overwhelmingly positive feedback with the new changes and went forward into development and QA.

The problems

From The Business Perspective

• Relieve customer pains by making modal system easier to use
• Need better alignment between design and Dev
• Save money by creating less iterations
• Use this project as a springboard for the complete software redesign

The solutions

From The UI/UX perspective

• Visual style guides
• Error handling rules and placement
• Icon usage system
• Font types, style & usage
• Modal standard sizes
• Wizard system
• Padding rules
• Point out to new developers where these modals come from
• Define animations using Principle App

In the past, there were general rules on how to design the UI/UX, but there weren't definitive guidelines on how to design to the pixel and mental model. A designer would design based off of old designs, but didn't have a place to go to solve the complex little issues. Over the years the modals started to vary all over the app with different UI/UX for the same designs. We made a list of high level tasks that we needed to accomplish with this project. It looked something like this.

The work:

Visual styles

As part of a larger project, the redesign of Marketo UI/UX, we needed to identify what our new styles would be. As a team, we decided on a modern light visual aesthetic. We also decided on our primary action color of purple, which is heavily branded throughout the company. This design helped contribute to the gray 1 pixel line separators, background gray, button styles/colors and heading font style throughout the app design.

Error handling rules and placement

Error handling can get very tricky in an enterprise app, so we had to sit down and have some sprints about all the variables that can happen within different constructs. We decided to create rules for different error types. Destructive error animates a warning above the modal like seen below, required entry highlights the field and has a general warning inline below the field and an in-page error will throw a general error modal with a specific message if needed.

Icon usage and padding rules

Marketo is a very icon heavy app. At a high level, there are many different types of assets and campaigns that can be run. Also, most of our users have a large amount of activity in their navigation tree, so they can use the icons to identify type, then scan for names. After some team design sprints, we decided on a standard icon library to use as part of the redesign and a standard icon size for the modals and the general app design.

In parallel to this effort we mapped out a standard of padding practices and translated this to the lead UI developer. He used a system called vertical rhythm for the whole schema. This meant that after the developer language library was created that there would be no arbitrary padding, it would be enforced with the rare exception to override.

Font types, style & usage

We chose 2 fonts to represent the core of the app, Muli as our heading font and Lato as our core app font. We also created rules and sizes in order to align with the developers.

Modal standard sizes

As I designed different modals we wanted to keep a level of consistency with width. We decided along with the development on 3 main sizes to work with after all the modals were created. This would lend a level of consistency for the users as we had previously had modals dictated by content. This system didn't scale well and often looked bad.

Wizard system and multi screen modals

The navigation for our previous wizard system was very confusing. In some interaction there would be upwards of 4 buttons all stacked together and all on one side of the modal. We split the navigation into 2 sides, having cancel on the left forward and back on the right side, taking care to avoid any situations that would require more than one CTA.

We also redesigned the step progress UI to be more intuitive and modern.

Point out to new developers where these modals come from

When we started the redesign project there were only a handful of developers and most of them were new to Marketo. As they were learning the software, we created a modal audit to showed them the entry point of the modals, which sped up the logic of what was being displayed.

In closing

All told, this was an extremely successful internal and external project that helped define systems and also helped to establish some work flows for the Dev, PM and UX teams. Much more work was done to finish detailing the pattern library, but I will create a whole separate project for that.