4

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?

6
  • 2
    What's the difference, or separation, between UX design and UX engineering you're referencing? Engineers use the same heuristics as everybody. They're engineering designs. What's an example of a UX engineering-specific heuristic? You mean engineers as users?
    – moot
    Aug 9 at 21:37
  • There was also similar question (just for indicating conceptual identicality), which i don't preferably mainly categorize the answers like one of the below did. Currently not have enough time to respond in detail but neither any of them represents the way in terms of what the term UX engineering does nor not most of the UX'ers join the idea that UX has or has to be involved in development. Aug 16 at 6:25
  • Here is the link I forgot to anchor, ux.stackexchange.com/questions/119462/… Aug 18 at 7:50
  • @moot When I was first thinking of this question, it was while thinking about how the engineering concept of "time to first paint", or many other engineering related concepts that translate eventually into UX don't really have a home in a typical UX hueristic evaluation, even though page load speed and it's constituent concepts are such a critical elements of UX. I wanted to know if I was on the right track for thinking of it in this way, and if there might be more granular, component-based concepts that I might apply to my work.
    – G.Mart
    Aug 19 at 16:28
  • I'm a programmer and do both development and design. The main problem is that talking about engineering is talking about how things work which shouldn't affect the user. Even load time is really design. I know it's all code but good programming and optimization aren't heuristics and programming heuristics like how to search data is too far removed from the end user's experience to really count
    – moot
    Aug 22 at 16:31
2

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:

  • Happiness: How do users feel about your product? Happiness is typically measured by user satisfaction surveys, app ratings and reviews, and net promoter score.
  • Engagement: How often are people coming back to use the product? Engagement can be measured by number of visits per user per week, session length, or a key action, like the number of photos uploaded or songs listened to per user per day.
  • Adoption: How many people complete the onboarding process and become regular users? Adoption is measured by number of new users over a period of time or percentage of customers using a new feature.
  • Retention: What percentage of users are returning to the product? Retention is measured by churn.
  • Task success: Can users achieve their goal or task quickly and easily? Task success is measured by factors like efficiency (how long it takes users to complete the task) effectiveness (percent of tasks completed), and error rate.

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.

  • Modularity - I think this is important because it gives an indication of how flexible and adaptable the whole system/process is, and therefore how resilient or resistant it is to changes over time
  • Reusability - another one that is critical in design because it shows the value of the system/process, not just what is reusable, but what is actually being reused frequently
  • Adoption - I think if there are key elements of a system/process that is valuable then it is likely not just to be used, but extended or adopted for use by other people for their own use cases
  • Sustainability - this is an interesting one because I think it captures the essence of a well-design or thought out system/process; this means that the cost of keeping things running is not outstripping the value it provides, and that within the lifetime or lifecycle of this system/process it minimizes waste and maximizes value to the users

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.

1
  • Thank you, this is an excellent answer.
    – G.Mart
    Aug 19 at 16:21
2

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:

ACCESSIBILITY HEURISTICS:

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.

1
  • 1
    This is a great answer, thank you
    – G.Mart
    Aug 19 at 16:21
2

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.

  1. Visibility of System Status
  2. Match between System and the Real World
  3. User Control and Freedom
  4. Consistency and Standards
  5. Error Prevention
  6. Recognition Rather Than Recall
  7. Flexibility and Efficiency of Use
  8. Aesthetic and Minimalist Design
  9. Recognize, Diagnose, and Recover from Errors
  10. Help and Documentation

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.

1
  • Thank you for your thoughtful answer
    – G.Mart
    Aug 19 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.