Service Eligibility

Part of the customer order experience on the DIRECTV website is entering either a service address, delivery address, or both during the checkout process. When customers enter their address, it is run through several validation databases. When an address is determined to be invalid, the customer needs to be notified that the address is invalid and they are:

• Prompted to enter a new address.
• Informed that they cannot place an order.
• Redirected to a flow where their address isn't required.
• Allowed to proceed with additional requirements.

Problem

How do we keep customers from abandoning their order when their address can't be validated?

Solution

Customers will be presented with in-page errors or modals with instructions for how to proceed when their address cannot be validated. Error messages will either include a phone number to call for assistance or a way to redirect around their error.

My Role

UX Writer - I drafted the copy for the error messages, form fields, and redirect modal. In this role, I partnered directly with a UX Designer and Producer, and worked with a Product Owner, developers, and other internal stakeholders to clarify the needs for this request.

Tools

Microsoft Word‍

Most DIRECTV UX writing is contained in Content Requirements Documents (CRDs). CRDs let writers add extensive notes including alt text, conditional formatting or display changes, and link targets. CRDs also let developers copy and paste content directly into code.

Figma

UX Designers create frames in Figma. Although I worked primarily in Microsoft Word, I also tested content in Figma wireframes for fit. Most content work in Figma is done prior to our first product demo to let stakeholders see what content we are proposing while they are reviewing the design.

Process

The UX team received very little guidance for this assignment. We were provided a list of error codes with either a "Red," "Green," or "Conditional Green" notation:

• A Red notation meant that the customer reached a hardstop and could not continue in that flow. They would either need to switch to a new flow that allowed them to skip the address validation process (e.g., switch to streaming without a DIRECTV device instead of streaming with a DIRECTV device) or they'd need to abandon their order.
• A Green notation meant that the customer's address check cleared and they were able to proceed as usual. There were not required design changes for this.
• A Conditional Green notation meant that the customer could continue with their order, but only if they took certain additional steps later on in the checkout flow.

Because of the lack of clear guidance on what was required, the UX designer and I laid out a rough rubric over a long meeting to break the assignment into different scenarios:

• Red scenarios:
  
  • A validation error where the customer is hard-stopped, but would be provided a phone number to call.
  • A modal where the customer would be told that satellite service was not available at their address, where they'd be given the opportunity to switch to a streaming package.
  • An in-page error telling the customer that delivery was not available to their address, where they could instead switch to streaming without a device.
• Conditional Green scenarios:
  
  • A modal where a customer would need to enter a different service address or they'd need to enter a different address at payment and also sign up for paperless billing.
  • A form field for the satellite installation scheduler page where customers would need to provide instructions on how to reach their home address.

Content Progression

Hard-stop Validation

For the hard-stop validation error, we originally wanted to tell the customer to enter a different address into the form or call for assistance. After presenting this to stakeholders, we determined we could cover a wider range of errors if we asked them to check the address and update it. This would cover instances where the validation error was because of a simple typo.

‍

Satellite Not Available

The modal advising customers to switch from a satellite order to streaming service started with very minimal copy. The first iteration was a simple change of the modal heading, intended to improve clarity for the customer in case they don't read all of the body copy. The second iteration was our final copy. This modal was redesigned to match a similar modal that had previously been used on the DIRECTV site. We updated the header again, added the address the customer entered, and made the body message more positive. We also added a call-to-action that would redirect the user to the same package they originally selected, but in the streaming flow instead of the satellite flow.

A last-minute addition to our story was an instance where the validation tools identified the customer's address as a business address. For this, we reused the same modal design, but modified the copy to push customers to call our Business sales team.

‍

Switch to Streaming Without a Device

The third in-page error I originally wrote would explain to the customer that DIRECTV could not deliver to their address and would encourage them to switch to streaming without a device. Due to coding complications, and problems with customers missing certain offers if they were redirected using that link, the Product Owner and other stakeholders suggested that we abandon the link. I replaced it with similar language to our first in-page error and a phone number the customer could call for further information and assistance.

‍

Billing Address Required

For some customers, their address would be valid everywhere except with the U.S. Postal Service. This meant that we could provide them with service, but couldn't actually send them any mail. In that instance, we'd need to have the customer give us a different billing address or sign up for paperless billing. Originally, I wrote the modal to give them the option to update their service address and pushed the new billing address to further into the checkout flow. After speaking to stakeholders and particularly development leads and the Product Owner, we determined that it would be better to collect the billing address immediately. The first iteration made a number of changes:

• Changed from updating the service address to adding a billing address.
• Added the current service address with a link to change that address instead of updating their billing address.
• Removed the First and Last name fields, since that information shouldn't change at this step in the order.
• Updated the button copy at the bottom of the modal to align with the new address collection.

After making these changes, I presented this copy to a wider team of developers and to the UX designer assigned to this project. We determined that letting users skip adding a billing address here only to require it later in the flow wouldn't make any sense, so I updated the button copy to only allow customers to add a billing address or edit their service address. I also updated the body copy based on feedback from the Product Owner and to shorted that section. I removed the link below the service address, since the close icon at the top of the modal and the "Edit my service address" button both let the customer take that action already.

‍

Technician Notes

Customers whose addresses can't be validated with the U.S. Postal Service would need to provide details instructions to satellite installation technicians on how to reach their homes. Originally, this was a required form field that would only apply to customers who fell into this category. I drafted the copy to explain that we would need directions to the customer's home and any other pertinent information. I struggled a bit with this copy because we wanted to keep it as short as possible since it appeared at the very bottom of a form page.

After completing the initial draft, the UX designer and I agreed that it would be both useful and relatively simple to make the form field appear for all customers scheduling an installation, but we would need different copy when it wasn't a required field. For these customers, I removed the asterisk noting the required section, changed the field label to say "optional," and changed the body copy to explain what types information we might find useful.

Results

At the time that my employment with DIRECTV ended, this content was being coded and put into production. It was very clear from the beginning of this project that it would only impact a small number of users, but I received positive feedback from the Product Owner, UX Designer, and development team on my flexibility in adjusting the content to changing requests and my ability to address multiple unique scenarios with relatively simple copy.