User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Noting that UX engineering is a fairly expansive term, I'll contextualize this to UX engineering as it relates to component prototyping and development, UI architecture, and maintenance.
What kind of heuristics might a UX engineer promote to more effectively evaluate their components?
It seems logical to channel some of the many well-documented UX design heuristics like consistency and use of standards, but what might be some UX Engineering specific heuristics which can compliment these?
Within the context that you are referring to when it comes to UX engineering, there are some interesting points to raise when it comes to component prototyping and development, UI architecture, and maintenance.
The reason why I bring this point up is because the activities relating to prototyping, UI architecture and maintenance is relevant not only to the user of the interface, but it also affects the person who has to use and manage these artifacts plus follow the process to design and deliver the interfaces.
Let's look at the first part that relates to the user. You have all the typical things that you might measure when it comes to user experience and in particular usability (which is generally the fundamental thing to get right first). You can find examples of these when you search the key words or tags on UXSE or Google for 'measure' and 'user experience' to see things like Google's HEART framework, various usability metrics you can measure and so on.
Google's HEART framework metrics:
Then there's the other aspect of the things you can evaluate based on the internal facing user (i.e. the person who has to apply and update/maintain) the processes, artifacts and tools. Not surprisingly, most of the frameworks and metrics that can be applied to external users are equally relevant here, so I'll point out a couple that are probably a little bit different.
How you measure a lot of these things will depend on the exact details, but hopefully this gives you some idea of where you can start looking to compile your own list.
All the UX design heuristics apply also in Engineering, of course, and are based on the technical requirements of WCAG, but World Wide Web Consortium (W3C) published a document that focuses more on the Dev:
Heuristic 1: Provide alternative equivalents to make information suitable for auditive, visual, and tactile channels. In that way it is possible to follow the presentation even if a user has limitations with some senses, some cognitive limitations or the device cannot handle some media very well.
As text is easy to create and easy to transfer to almost any sense with the help of assistive technologies it can usually be used as an alternative to other media. For instance, assistive technology for a blind user can easily change an image with alternative text to voice or Braille format. With timed material, such as animations and video, the text often needs synchronization and therefore it might be easier to provide it also directly in audio. Section 3.1 explains more about alternative equivalents and their use.
Heuristic 2: Provide means to select equivalent content. Users should be provided flexible means to access the equivalent content in any combination that is most suitable for them because of their disabilities or the limitations of the used devices.
Normally these means are provided by user agents but also some languages provide switches for selecting content. If author provides the default selections, he should make sure that nothing in his design prevents flexible user control. Sometimes the defaults can also be automatically negotiated.
Heuristic 3:Provide user control for presentation by separating it from the rest of the content. This benefits users with disabilities or devices with limited capability.
For instance, a blind user may want to define that emphasized text is read in a louder voice, or a user with low vision can change the fonts to a larger size and use colors that have more contrast. This principle can be implemented by using style sheet technology. It is discussed more in Section 3.3.
Heuristic 4: Provide device independent interaction so that users with different input and output devices can easily get to all the available functionality.
This is often reached by using a user agent that can provide access to the functions by emulating mouse. However, it is good to provide shortcuts that get users to functions without any need to use mouse or spatial positioning. This is hardest when walking in a 3D world, but doing it might also help others not so familiar with 3D navigation with a mouse.
Heuristic 5: Provide semantics for structure. This helps provide alternative ways for user navigation and orientation. This can also help the use of alternative presentations. Use authoring tools that support this.
Semantics can be provided by using the elements of the language in a correct way and by describing the site and page navigation and the structured components with other available means. The languages usually include general grouping elements that can be used to add semantics. The other means include the use of class hierarchy and semantic languages, such as Resource Description Framework (RDF) [11]. These are discussed in more detail in Section 3.5.
Heuristic 6: Provide reusable components. This helps users who use a media that makes it more laborious to compare the components.
Multimedia often contains application-defined components that are repeated several times. Especially graphics components might be repeated but also some video sequences or houses or other objects in a 3D model might contain the same elements. A user who is examining a structured image visually can do it much faster than a blind user navigating through the structure and the equivalent alternative explanations or even the graphical components. Reuse of components saves time as a model component can be examined only once.
And again, the majority of the WCAG 2.1 success criteria fit into Nielsen’s 10 Usability Heuristics, and this is something usually known by the Engineers.
The heuristics for UX engineering (UXE) are the same as for UX design (UXD). Both disciplines seek to create a UI with good UX and heuristics tend be rather general. Thus, the same heuristics apply equally to a UI as represented at the wireframe or illustration stage (UXD) as to a UI as coded in prototype or production (UXE).
Heuristics
As for specific heuristics, it’s hard to beat the tried and true 10 Nielson heuristics from the 1990s.
Evaluate the implementation UX
For example, consider Heuristic #1. UXDer may specify a spinner to indicate a busy status in the system. However, it is up to the UXEer to ensure the spinner actually provides accurate status information –that the spinner starts spinning promptly at the right time, that it keeps spinning steadily while the system is busy, and stops promptly when the system is idle.
Evaluate the UX of design in technical context
Furthermore, the UXEer has the expertise to critique the UXD on the heuristics in the context of what is technically feasible. For example, the UXEer may recognize that it’s not only possible to detect if the system is busy, but also its progress towards completion. Thus the UXEer may recommend that they replace the spinner with a progress bar to improve the visibility of the system status.
Evaluate the design details determined at implementation
Depending on your organization and personnel on the project, the division between UXD and UXE can vary. You may find that often the specs from the UXDer lack details especially for certain edge cases. For example, the UXDer may be vague on how errors, especially technical errors (e.g., lost of backend connection) are handled. It then falls on the UXEer to essentially specify (and implement) the design (e.g., how an error message is shown, what is its wording and appearance, whether it should be modal or not, and what options may be provided with it, like a Reconnect button). Such designs can be subjected to a heuristic review (Numbers 1, 2, 3, 4, 6, 9, and 10 come to mind, in this case).
Summary
So there are no UX heuristics for UXE that aren't also in UXD. This should be hardly surprising since a UXE is essentially a UX designer who knows how to code (or a developer who knows how to design UIs). Just as the coding standards and source control practices of development apply unaltered to UXE, the heuristics and principles of UX apply unaltered to UXE. The heuristics and principles we have are sufficiently general and there is no need to even re-word them for UXE.
