How to classify UI change according to the conventional commits specification?

Based on the conventional commits how are mere UI changes supposed to be classified? For example suppose a logout button is moved from the bottom of the screen to the top, an icon is added next to the text, and there is a new animation. Other then that nothing changes from a functional perspective.

My confusion comes from this (probably wrong) reasoning. You can't use any of the following because:

feat: it's not a new feature
fix: there isn't any bug to fix
perf: performance is not touched upon
refactor: this could be the case following the Angular definition of refactor "A code change that neither fixes a bug nor adds a feature", but not using the Wikipedia definition of refactor "code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior"
style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc). It's self evident that this isn't the case

Solution

A feature does not need to be very big. Despite the code change being very small, the relocation of the log out link is user-facing, and thus is a feature. Using the "feat" prefix for your commit is acceptable.

feat: moved logout link to top of page, resolves #1234

On the other hand, if the log out link was never supposed to be at the bottom, and moving it to the top corrected that, then use "fix:" before your message.

fix: moved logout link to top of page. Fixes #1234

The article you link to mentions quite a bit about semantic versioning, and seems to be geared more towards APIs rather than entire applications, so exact translations to application changes will not exist, but you can make some correlations.