Back

DemocracyLab

What is DemocracyLab?

DemocracyLab is a tech-for-good nonprofit that offers a platform for social entrepreneurs and skilled volunteers to work together on projects that advance the public good.

My Role at DemocracyLab

As one of the first UX writers to join the design team, I’ve had the opportunity to work with newer writers, as well as a number of UX designers, UX researchers, developers, and other members of the design team for regular reviews and feedback sessions.

Select Work

Back

DemocracyLab: Create Project Flow

Overview

Projects are the foundation of the DemocracyLab platform, so it is important that project creation is easy and user friendly. During a site-wide audit performed by members of the design team, multiple areas of friction were identified and remote moderated usability testing was conducted to follow up on these findings. 

I worked with the research team and reviewed testing sessions, compiled feedback in Google Sheets and Figma, and created the final report with recommendations for improvements.

Recommended improvements* included the following, which are detailed below:

• Error notification and clarity of instructions

• Clarification of final step in process

Copy solutions were based on consideration of user needs and application of best practices. Design updates are in the process of being implemented on the site.

*Additional recommendations include updates to the progress bar and changing the placement of the project image.

Error Notification and Clarity of Instructions

These two items are grouped together since clarity of instructions can help prevent errors from happening in the first place.

Problem

The existing system for error notifications is a list of black bullet-point ‘requirements’ at the bottom of the screen. Some errors were results of users not knowing which fields were required. The flow had inconsistent labeling of required/optional fields. Throughout the process, instructions (along with headers and labels) could be vague or confusing.

Process

Review of Testing

• Some testers didn’t notice the error messages at all.

• Others weren’t sure if the bulleted items were error messages or something else.

• Testers were confused and got stuck in some areas when labels or instructions weren’t clear.

• Others weren’t sure what fields they could skip and still continue with the process.

Collaboration

I worked with a UX designer (who was working to overhaul the error notification system and guidelines for required/optional fields across the site) to build out design options.

• We worked collaboratively on placement of error messages, ensuring that they were in contextually relevant locations and that the copy helped users fix their error.

• We also sought to add clear, actionable labels and guidance and including reminders where users could leave fields blank.

Review with the Design Team

Design progress was presented at weekly meetings with the Design team and feedback was incorporated into updated designs.

• The executive director and members of the development team were also present at these meetings.

Solution

Error Notification

• Error notifications were moved from the bottom of the screen to below each relevant field. 

• Color was changed from black to red to grab user’s attention.

• Copy was chosen to be clear, conversational, and actionable.

Clarity of Instructions

• Labels, instructions, and/or placeholder copy was added where needed.

  • For example, we added https:// as placeholder text on Step 4 to nudge users to add a URL (instead of a platform name or username).

• Section headings were slightly modified to better reflect what is being requested.

• Updated instructions offer more detail and a reminder that users can leave input fields blank.

  • While UX writing aims to be concise, this is an example of more text being necessary for the user to accomplish their goal.

Additional Testing

Internal testing was performed on whether or not to include an icon with the error message. Results were split down the middle.

Clarification of Final Step in Process

Problem

The final step of the Create Project process allows the user to review what they have added in previous steps and then proceed to submit their created project. The submitted project is then reviewed by staff. If approved, the project becomes active on the site.

• The instructions say to review the details and click PUBLISH once the user is ready to publish their project. 

• However, the next screen shows Owned Projects with the Project Status as Unpublished. This inconsistency confounded many testers. 

• Almost all testers missed the banner at the top of the screen that noted the project is “awaiting approval”.

Process

Review of Testing

• A number of testers thought they did something wrong when they saw the Unpublished status after clicking the PUBLISH button.

• Some commented that the message at the top of the screen was overlooked since it was assumed it was the same banner that was promoting the hackathon (which was in the same place - and the same color - on previous screens).

Collaboration

The initial work on this step was started by another UX writer. I offered feedback on her work and then continued with the task when she left DemocracyLab. 

• Together we addressed the issue of the current copy not reflecting what the user could expect when clicking the CTA, or the current status of the project.

• One challenge we encountered was whether to change the status to Pending or Under Review. It was important to make this decision so we could be consistent with the success message and email.

I then worked with a UX designer to change the way the appearance of the notification.

• We decided that a desktop notification/toast would be more noticeable than the current orange banner.

• We worked with the Development team to determine how to proceed with this new component. The site is built in Bootstrap and has certain limitations.

Review with the Design Team

• Progress was again presented at weekly meetings with the Design team. (The executive director and members of the development team were also present at these meetings.)

• We raised questions about the status and the Head of Development shared that Pending is used for volunteers waiting to be added to a project. We chose to use Under Review for projects that have not yet been approved.

Solution

Last Step

• To better reflect the action of the button, we changed copy from PUBLISH to Submit Project.

• We aligned the header message with the button copy.

• We also changed the capitalization from ALL CAPS to Title Case, since this is what was determined in the style guide for CTA buttons.

Owned Projects

• The Project Status was changed from Unpublished to Under Review, to more accurately reflect the state of the project.

• The new notification says:

  
  PROJECT SUBMITTED
  [Project Name] is now under review.
  We’ll let you know when your project is approved and active.
  (Expect an email in 1-2 business days.)

Additional Testing

The new notifications were tested internally, and results were mixed. It was determined that we would garner clearer results with a modified test. The new test includes both copy and notification questions and will be conducted soon.

Next Steps

Testing effectiveness

Once these changes are pushed to the live site, we can test effectiveness in a number of ways:

• Overall conversion rate of the Create Project flow.

• Drop-off rates on each page.

Next Project