Take for example the SHA-256 hash of a null string:
e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855
It is shown here with break spaces at 32-bit intervals, 8 sets of 8 characters. It is reasonably readable by a human, but it is a little long. A 512-bit hash is even longer:
cf83e135 7eefb8bd f1542850 d66d8007 d620e405 0b5715dc 83f4a921 d36ce9ce
47d0d13c 5d85f2b0 ff8318d2 877eec2f 63b931bd 47417a81 a538327a f927da3e
Still reasonably readable if you pay attention, though it may be hard to keep track of where you are reading if you are attempting to compare it to another block. Generally the hash you are comparing it against will either be the same or very different.
When comparing 2 identical hashes, you need to compare the entire hash to be sure. For PGPfone, a word list was developed to compare the authentication strings. This was designed primarily for comparison of a voice channel, each byte of comparison takes 1 word. The EFF word list is primarily designed for password use to replace the Diceware word list. You need 2 words from these lists to encode 3 bytes of the hash. While easier to compare than hex characters, a 256-bit hash would need 22 EFF words or 32 PGP words to display, taking up a lot of screen space, like this example:
reimburse pavilion starlight subtly jolliness unretired crimp peculiar polar partly ascent erased brisket small engaged cabdriver molehill alibi hardly reviving acid container
I honestly do not think that is much easier to compare than a hex string. For a visual comparison it makes sense to use the properties of human vision to reduce the amount of characters compared. We see colors (generally) with great accuracy, and can tell that red is different than blue without having to think. We can see alignment of visual information within a block. We can see if something is tilted or rotated slightly, or is offset from a common line.
You could choose 4096 words from the EFF list, and use 2 bits for color, 1 bit for caps/lower case, and 1 bit for bold+underline, and you could shorten the words required to 1 per byte pair.
Selecting the shortest words would make that more effective. I used 1 bit for alignment, 2 bits for color, and 5 bits for character to come up with an example of encoding bytes that requires a single character per byte. The data is then aligned in a 20 character wide grid, with 16 characters per row, and as many rows as required to display the hash. SHA-256 would need 2 rows.
For each byte, we encode the first 5 bits as a base 32 character, 0-9,A-Y, skipping IOS. The next 2 bits determines the color, 00=0xFF0000, 01=0x00FF00, 10=0x0000FF, 11=0x000000. Those colors are for computer display on a white background for someone who is not color blind, the colors can be changed for CMYK print, other backgrounds, etc. The final bit determines "alignment" within the grid. It can be a change in vertical or horizontal alignment within the grid squares, or a slight rotation, or bold print, font size, or some combination. The parity of the alignment bits within a 32-bit block determines the left or right alignment of the 4 bytes in a 5 space wide section of the row.
Using an offset of top aligned bold, e3b0c442 might be displayed as such:
E3 = 11100 01 1 = char 28 "V", green, offset
B0 = 10110 00 0 = char 22 "N", red
C4 = 11000 10 0 = char 24 "Q", blue
42 = 01000 01 0 = char 8 "8", green
I will follow up with a complete hash example when I have the time, but the TLDR is to make use of the way we perceive visual information to both speed up the comparison while reducing the amount of pixes/area required to display the hash. Where nothing more than plain text is available, broken aligned hexidecimal or a high density wordlist are probably the best options. The algorithm used for SSH key fingerprint randomart is subject to collisions, fc94b0c1 e5b0987c 58439976 97ee9fb7 and fc94d0b8 21d9c84d 27439976 97ee9fb7 should produce the same visual fingerprint, for example.