En så kallad "guideline" är en samling dokument som beskriver hur ett GUI (eller någon annan form av gränssnitt) ska fungera. De beskriver inte så mycket hur man programmerar ett gränssnitt utan istället hur själva interaktionen "ska upplevas" av användaren.

När man läser en guideline så kan lätt bli lite frustrerad, endera på grund av att man bara hittat allmänna råd som man inte kan använda direkt och/eller så är det så mycket att läsa att man aldrig hittar det man söker. Detta är ganska typiskt då det är svårt att beskriva något så att det är användbart utan att bli alltför detaljerad ... risken blir då att man är för översiktlig och man inte får ut nåt av "guidelinen".

Det är naturligtvis omöjligt att skriva ett dokument som beskriver interaktionen utan man ska väl närmast se dokumentet som ett närmevärde. Ett bra sätt att få fram själva känslan är att erbjuda ett eller flera exempelprogram på hur ett program ska fungera. Kom ihåg att det är fullt möjligt att skriva ett program som följer alla guidelines men som inte har den "rätta känslan".

Man kan också snart se att i samma guideline så får man råd som motsäger varandra ... i sådana fall får man som designer göra sitt bästa och göra ett val som är så bra som möjligt. I de fall där du får en konflikt mellan "allmänna" sanningar inom MDI och en guideline för en viss plattform är det "guidelinen" som gäller. Håller du på med att "porta" ett program från en plattform till en annan är det mycket viktigt att du verkligen kollar upp hur saker och ting fungerar på den nya plattformen och inte gör som den gamla plattformen. Ett exempel på de svårigheter som kan uppstå är Javas GUI som i en del fall har väldigt dålig "mappning" till hur program normalt fungerar på en viss plattform. Detta kan ge upphov till stor förvirring hos användarna.