Human-machine interfaces

Human-machine interfaces (HMI, IHM, Interfaces Homme-machine) are interfaces connecting humans and machines, for instance, a mail client. More broadly, this includes any programs or websites.

You must think a lot about how you should create one, and that's the purpose of this course. You will need to think πŸ€” about

  • where πŸ—ΊοΈ: layout of your application
  • what πŸ—ƒοΈ: which element is required, and which one isn't...
  • how πŸ–‡οΈ: what are your menus, are they simple and intuitive?

We usually create a mockup (maquette) first. Each screen of the application is called a wireframe. Once every screen is created, you will add actions between your screens, which include stuff like what happens when the user hover/press/click/... on a button/... The final output with interconnected wireframes is called a wireflow.

You can create wireframes/wireflows using

  • Justinmind (paid, free trial, really good πŸš€)
  • Moqups (free with a limit, account required, quite good πŸ“Œ)
  • Diagrams (fast, poor quality)
  • Sketch (macOS, πŸ‘»)
  • Photoshop (paid, for professionals)
  • Bootstrap (my favorite 😍, require advanced Bootstrap+CSS skills)

Other tools


πŸ‘² Users πŸ‘²

Before coding some application, you must think about what kinds of users will use it

  • Language/country
  • Age
  • Color-blind, partially sighted ...
  • Culture
  • Devices (computer? Keyboard? Mouse?)
  • Screen orientation, Screen size
  • Day/Night mode
  • Knowledge about computers/...
  • Illiterate?

You can't make something that would be perfect for everyone, but try to make some categories of users and provide them with an application, that would aim to satisfy most of their requests. For instance, you can

  • Make a website/app per country,
  • Add a settings tab to enable the day/night mode,
  • Think about the color-blind users when designing,
  • Make your website/app responsive
  • ...

πŸ“„ Steps πŸ“„

Usual steps

  1. Create some categories of users
  2. Ask people matching your categories where they would go to find XXX in the menus, ... to test your interface.
  3. Create UML's diagrams to formalize the interactions between the application and users
  4. Make a static mock-up
  5. Test your mock-up
  6. Make a dynamic mock-up (links working, some code, ...)
  7. Test again

OR you can follow my steps

  1. Create a dynamic mock-up
  2. And repeat these steps
    1. Test and reviews by users
    2. Sort changes to be made
    3. Implement one or more changes

Jakob Nielsen

Jakob Nielsen wrote the 10 principles that you should MUST 😠 take into account. See ten usability heuristics.

  1. Keep the user updated on what's happening

    • if something is being loaded, ... tell it to the user.
    • the user should know where he is (ex: which page?)
    • buttons should have a visual change when they are hovered/pressed/...
  2. Do not do something complex, follow the conventions

    • ex: the close button is at the top-right of the screen
    • Skeuomorph design: we are expecting an online book to work the same as a real one
  3. Let the user be free

    • allow the user to cancel an action
    • user must see they can "escape"
  4. Norms, directives, habits

    • ex: we are expecting a software of the same family to be similar
    • we are expecting a πŸ›’ shopping cart on a marketing website to see the list of our items
  5. Prevents errors

    • do not let the user make mistakes, you should code or use the right kind of input field if you expect a specific kind of value.
    • asking the user confirmation might also be a good practice.
    • you may add a small help, an example, or a message saying what you are expecting
  1. Users shouldn't need to learn

    A MCQ is easier than an open question... Make it so that the user will recognize instead of remembering. You may use a particular kind of style or you may add tips.

  2. Flexibility

    • make it easy to learn
    • and easy for pros to skip some steps, for example using shortcuts.
  3. Aesthetic

    Do not write hundreds of words, add useless images, ... to say something that would fit in less than 10 words. Be clear and concise.

  4. Robustness

    You should handle any kind of error or mistake.

  5. Documentation

    As a last resort, you may add documentation for complex applications.


Additional notes

  • πŸ€”οΈ It's better to have one relatively long loading time rather than many for resources that the user is likely to request
  • 🦣 A screen will most likely have more width than height, so you should exploit the width.

  • 🧼 If you need more than 3 clicks to do one action, and you do this action often, then you MUST re-think your interface.


πŸ‘» To-do πŸ‘»

Stuff that I found, but never read/used yet.