Lorenço Oliveira

reporter // producer // web designer

UX Writing Study: CEEE Virtual Agency

Published on July 27, 2022

Following the CEE case study, I now leave for another (UX Writing) element of the Virtual Agency side menu. If you don't know what I'm talking about here, go back to the previous post of this series:

> UX Design Study: CEE Virtual Agency (Part 1)

In this post I will exemplify some questions involving the writing of a descriptive text and labels that make up one of the elements of the home page. Let's untangle the service protocols page.

Consult Request Services

This element is a very secondary function within the scope of user options. Nevertheless, the idea here is to provide control of the processes, because each action taken within the platform generates a protocol that can be verified in this part. The structure is once again quite simple:

Description of elements:

  • Title [See Request Services]
  • Required-descriptive text [Enter your Consumer Unit number or your Service Request number.]
  • Label 1 [Your code:]
  • Input field 1
  • Label 2 [Protocol:]
  • Input field 2
  • Input field 3
  • Button [Search]
  • Button [ Clears Throat ]
  • Splitter

The body structure of this page, apparently similar to the previous ones, actually has interesting differences to observe. I will point out here a few points of attention which I identify:

  • The title, although understandable, has a grammatical syntax error. The phrase "Consult Request Services" can work smoothly to name a directory (e.g. /consult-solicitation-service), but the absence of the preposition "of" can cause strangeness and loss of meaning.
  • Because of this possible loss of meaning, a dynamic reading of the element in the menu could make the user see more than one possible option in this case: (1) See Request and (2) Services;
  • The imperative-descriptive text has some problems that seem very foolish, but may give rise to misunderstanding. Although there are no syntax errors as in the title, the text does not connect exactly with the labels below. I'll explain better.

Two data can be entered into input fields:

  • Number of your Consumer Unit; or,
  • Number of your Service Request.

Let's see how the labels are named below:

  • Your code
  • Protocol

Although there is an obvious association for the user of the CEE, what given marriage with which? Will the user even interpret the possessive pronoun of the text ("his" Consumer Unit) with the pronoun in the label ("His" code)?

Of course, after a few attempts, the user will deduce that "Number of your Consumer Unit" is actually "Your Code" and that "Number of your Service Request" is "Protocol".

But at what cost do we do that? It may seem a minor detail in writing, but it cannot be assumed that all users will reason in the same way. Here, I think a brief correction in the imperative-descriptive text would greatly shorten the time on this page and contribute to a more effective experience. List two correction options (in bold):

  1. Enter your Consumer Unit number (code present in your invoice) or the number of your Service Request (protocol)
  2. Enter code of your Consumer Unit or protocol your Service Request;

More comments on this page

  • The mandatory-descriptive text does not follow the same aesthetic pattern as the texts of the other pages. Also, the use of a border around this site is attributed to Attention messages, which is not the case;
  • The input field 2 is not editable. There's no problem with that. however, the field could be in another color that signaled the inability to edit, like a lead ash.
  • The two buttons (Search and Clean) are very close to each other. Just insert/change the value of the object margin. See below how would the CSS code change to "mark: 5px:

Conclusion

Assuming that the user of the site will deduce exactly the paths we draw is part of the construction of the experience, but I consider it important to be aware of possible ambivalences. In the case of an electric power company, the target audience is quite broad, so the site user will also be very diverse.

This is the second part of a series of analyses I'm doing around the CEE website. My idea here is to study this site as a redesign case, explaining my decisions and going through UX Design processes.

> UX Forms Study: Virtual Agency CEE (Part 3)

If you liked this content, consider signing my NEWSLETTER to receive by email the posts of this Blog. It's free!

And feel free to follow me on social media:

Linkedin | Instagram

__

Featured photo by Fré Sonneveld ed Unsplash

EnglishenEnglishEnglish