Designing according to implementation models and why you should think twice about it

Today I wrote an answer on UX Stack Exchange that I thought I’d share here with a bit of extra elaboration. The questioner was seeking design suggestions for menu organization in a lightweight music player program. Here’s the UI the developer initially created (imagine this as a right-click menu):

credit: ‘Glenn1234’

Not the most intuitive (and in fact rather confusing) interface around! I was confused by the seeming duplication of ‘Jukebox Controls > Load Media’ and ‘File Controls > Load’, so the questioner clarified that ‘Load Media’ was for this function:

take a collection of music files and select specific files based on certain criteria and play them continually until the user stops the program

while plain old ‘Load’ was supposed to do this.

select/load specific files on demand.

Now the problem starts to become apparent. The ‘Load’ vs. ‘Load Media’ issue is just the most obvious symptom of what is going on here: the current menu was built around the implementation model of the program; that is to say, the way the music player actually works, from a technical perspective.

Translating literally from functions in code to functions in the UI is often an easy option – each control basically has to trigger a function in the code, clean and simple – and often will seem to make perfect sense to the developer. My guess is that the thinking often goes:

  • My code can do X, Y and Z.
  • The user interface to my code should let the user do X, Y and Z.
  • Hence my user interface should display X, Y and Z.

This looks sensible enough, but let’s replace X, Y and Z with some example features for a program that…let’s say I want a program that will delete all occurrences of the phrase ‘help im realy sleepy’ from an essay that I wrote too late at night. This is the only thing that the program is supposed to do (presumably ‘help im realy sleepy’ happens a lot) and all I want is to make my essay presentable as quickly as possible because it was due half an hour ago. This isn’t the most realistic example, but it gets the point across:

  • My code can select all occurrences of ‘help im realy sleepy’, delete selected text, and save the file.
  • The user interface to my code should let the user select all occurrences of ‘help im realy sleepy’, delete selected text, and save the file.
  • Hence my user interface should display buttons that let the user select all occurrences of ‘help im realy sleepy’, delete selected text, and save the file.

Let’s see how that goes…


Designing by the implementation model.

Hmm. A bit iffy. What’s wrong here?

Let’s go back to our friend with the music player. I’m guessing that someone using the program really just wants to load some music and start listening to their favorite songs. (Of course, you’d want to back this with user research, if possible.) This is the mental model of the user – the way the user thinks the system works or should work. Not how you, as a developer, know it works.

And the mental model is what needs to be designed for.

Likewise, a user doesn’t care if the music player program has two functions called loadFileset() and loadOneFile() in its code. In fact, the music player could make use of loadWAVFile() and loadMP3File() and a million other functions and the user wouldn’t care nor want to see them in the UI. Recall that ‘Load Media’ and ‘Load’ both implement the basic functionality of ‘load some music’. So why doesn’t the menu just get rid of the confusing duplicate and give me a way to load some music – whether one song or many – so I can start listening already?

The actual suggestion I gave in my answer was that the program’s functions seemed to fall into three logical groups:

  1. Load Music
  2. Play Music
  3. Settings (and stuff like About and Exit and whatever)

…so I would start reorganizing/thinking about my menu items from there. I would also argue that prev/next belong with the player controls instead of file controls. When playing music, files become tracks to users – they’re no longer just a bunch of .mp3 and .wma and .ogg files in a directory; they all become pieces of music and should be treated accordingly.

Here’s a last illustration with the fictional essay-cleanup tool discussed earlier. Remember the user of this program? She has an overdue essay, knows what exactly needs to be removed, and needs it done fast. Below is a possible way to simplify the UI so that the whole process better aligns with the mental model of ‘I’ll give this program my essay, press a button, and it will attempt to save me from my professor’s wrath’. We could even combine the De-sleepify and Save buttons. In fact, we could make the program automatically compose a grovelling apology email with the essay attached when you click the button. You get the idea.


(Hopefully) designing by the mental model.

Background reading on implementation, representation and mental models:…although the diagram there is definitely stolen from somewhere – I can’t remember which book; possibly About Face 3 by Alan Cooper (can someone verify? let me know in the comments)