I'm a product designer living in San Diego, California. I started my career 20 years ago, worked for a few in-house design departments, and afterwards had my own design consultancy. I then got interested in UX and product design and changed my career trajectory. Since, I have worked for DNN Software, Marketo and currently work for ServiceNow. Creating user experiences, functionality and beauty is not just my job, it's my passion.View my Works
The federal vertical was not getting met for a document signing feature between employees and HR agents. This was a very complicated feature and needed a lot of design concepting and thought put into it.
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 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.
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.
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.
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.
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.
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 ServiceNow HR team created a powerful campaign engine for internal employee communications. Unfortunately, it was complicated to use and hard to understand. This was my first project when I started working with the HR business unit and one of my favorites, due to simplifying the complex user experience and beautifying the feature.
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.
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.
After the wireframing phase was approved, I put together the intro screens and built out a prototype of what the team had agreed upon.
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.
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.
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.
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.
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.
I was tasked with rethinking and redesigning the Marketo Default Program Calendar. I worked with a dedicated dev team, product manager and my own design team to come up with new mental models and concepts to make this feature more appealing than it was in the past.
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.
From The Business Perspective
From The UI/UX Perspective
The numbers pertain to the marked up image below:
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:
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:
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.
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:
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.
We went though many variations, sprints and changes. Here is a look at the final UI polish and UX fixes.
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.
Agenda View (Day view similar, but no day label in left column)
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.
Hidden days in month and week views for more horizontal space
Tool tips in week and month view
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.
View filter panels
Global calendar asset visualized with globe icon
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.
Colors and icons explained at a glance
Global calendar icon explained at a glance
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.
Annotations for developers and PM
Starting point animations for devs
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.
As part of the larger redesign of Marketo, I was given the job of redesigning the modal system. As I designed I had to keep a very consistent set of rules in order to create patterns that could be used over and over again, even within the main parts of the app, such as inline error states, padding rules, font types, icon usage, etc.
From The Business Perspective
From The UI/UX perspective
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.
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.
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.
I worked closely with DNN's VP of Product, product managers and engineers through the full design cycle, including research, design sprints, presentations, wireframes, prototypes, revisions, high fidelity mockups, project management, QA and release.
We knew that we wanted to create a publishing feature for our content management system: Evoq Content. We studied the market, our competition and started researching. After the product manager created our official requirements doc we decided to hold a design sprint as this was a brand new feature.
We began by doing a week long sprint design sprint that was attended by the VP of Product, two designers, and two developers. This sprint is patterned after The Google Design Sprints with some variations tailored to DNN's organization. Our UX, flows, and persona findings steered us to wireframes.
After the high fidelity images and interactions were approved, we created prototypes with explicit directions. This way the developers had a very defined blueprint to work from and we didn't have to have as much back and forth during project management.
(Copy and paste link in browser)
Early InVision prototype:
(Copy and paste link in browser)
Publisher includes support for tags, images and social media sharing. Tags are a useful way to categorize content created by Publisher. Content managers use Evoq’s tags to organize content, which in turn makes it easier for site visitors to find what they need. Tags are a feature that’s common across numerous Evoq features.
Publisher includes integration with Disqus, a third-party commenting system used by many websites. To utilize Disqus commenting, users need to create a Disqus account for their organization. From there, they do a one-time set-up via the Evoq control bar.
Publisher auto-generates a “front page experience,” multiple sections of a site: Blog, News, Press Releases, Webinars, etc. The front page includes two slots for featured posts. This is used to highlight most recent (or, most important) content item. Below the featured posts, Publisher provides a paginated, three-column list of content items, complete with the article’s title and a selected image (taken from the article).
Publisher provides the same, easy editing experience that is found across Evoq products. The user creates Publisher content using the WYSIWYG (“What You See Is What You Get”) editor, which allows them to format text and add images and hyperlinks. The editor supports inline image editing, so the user can crop and resize images inline.
Content created by Publisher ties in with Evoq’s advanced workflow and content analytics. By using workflow, you can create an approval process to have new articles reviewed before they’re published to the site.
Content writers could have their blog posts reviewed by the marketing manager, who’d publish approved posts to the site. Alternatively, the marketing manager could send the post back to the submitter, asking for changes to be made.
In-context analytics mean that marketers have immediate access to key metrics on any page created by Publisher: page views traffic sources, time spent on page and much more.
Publisher automatically inserts social sharing buttons at the bottom of each article:
The sharing buttons make it easy for readers to promote content to personal social networks, helping to drive traffic back to their website.
All content created by Publisher is mobile-ready using responsive design. In addition to being mobile-ready to your site visitors, the Publisher user experience is also mobile-friendly. This means that users can create and edit content from a tablet or smartphone.
DNN Evoq is an enterprise level CMS software geared towards marketers. Recently, we designed a way for our users to tie into their 3rd party connectors, so that people can easily connect to their favorite apps and software, such as Salesforce, Marketo, Drop Box, Disqus and more.
As part of our framework redesign, we created what we call a "persona bar". The connectors can be accessed here. In essence it is a tool bar that slides out when the user logs in. There is a different tool set for each type of user: Content editors, Content managers and community managers and even more granular permissioning that can be set by the site administrator(s). Connectors increase organizational engagement, proven touchpoint data and also provides simpler workflows
A friends reunion app
I wanted to design an app that made it easier for friends to coordinate a reunion together. I did some research and used my own experiences to formulate some initial documentation. After designing the app I put together a presentation of the design process which I have detailed below.
(copy and paste in browser to download)
For the design I focused more on the user side of interactions when I started. I knew this would be the hardest part to accomplish. I wanted the app to be able to scale from a simple 1 time transaction, such as a dinner, to a full blown destination vacation with friends. The reason my wireframes may seem a bit complex is because this is the fully scaled out version.
Linda is trying to find out how to plan a complex destination vacation for an old set of friends. She wants to get everyone together to celebrate a mutual friend’s birthday party. After some Internet searches and chatting with friends, Linda decides to use Re•Dux.
Linda finds the app on the Re•Dux website and is re-directed to the app store where she downloads it.
Using her mobile phone, she signs up for the service with her email and password of choice. She is then asked if she would like to import contacts from Facebook or her email account. Next Linda is taken to an onboarding screen that shows her how the app functions on one simple screen. She clicks get started and the onboarding screen disappears to reveal the home screen beneath in empty state. Linda notices the prompt and clicks the “Create Reunion” button.
She is taken through a simple stepped process of how the reunion will shape up to be. My thoughts on this are that this app is fully scalable to handle a single event on one day, or a full-blown destination vacation over a multi-week period. The intent is to take the admin through the process very quickly and efficiently.
Now we get to the sign up process. The admin signs up just like the invitees: See the sign-up wireframes I have provided. If they choose to, they can skip this process and begin when ready, but they are prompted to create at least one item for each feature. The admin has inline edit permissions that a typical user does not. Also, the admin has analytics built into their dashboard and the ability to share admin privileges with others.
Overall, my thoughts on the app are that it takes away the pain of setting up by a few people, which normally happens, to creating a crowd-sourced setup/maintenance.
Contact me to chat about opportunities, technology, film making, comedy, or anything in between.Joe Richardson