I’m currently taking a few course at the Interaction Design Foundation. I have always been interested in UX, so it seemed like a good idea to take the time and expose myself to more ideas from that particular field. This seems especially important to me because when you are writing software, this (as I’d argue) is the prime factor as to whether what you are writing is useful or not.

I remember that during my time at Unviersity I was always a bit perplexed as to what the professor for Human Computer Interaction (HCI) was actually working on. I never took the time to find out about it, unfortunately, since the HCI course I’m now taking at IDF is absolutely eye-opening. It is taught by Alan Dix, who I was not familiar with at all before. Just in the opening videos, he made two very clever observations:

  • Over the last 20 years, the industry has shifted from boxed software that you are kinda stuck with to services. Services make it much easier to just switch to another service provider. They have an interest in keeping you. Sure, when you are unhappy with your purchase of a boxed copy of Outlook 97 you might try to return it or tell your friends not to get it, but in most cases the money is already spent.

    This puts much more of an emphasis on UX and making sure that your product is enjoyable to use. This seems like a sensible explanation as to why UX and HCI have become so much more important over the last few years.

  • There is a stark tension between the way that software is developed and the way that software is used: As a software developer, we are trying to actively decouple systems, make interfaces minimal and small, and make sure that everything is as independent from each other as possible. Maybe we can even get different teams to work on the single parts in parallel?

    Now, what’s the user’s perspective? When you start using a tool, you expect it to be coherent. Of course these things should work together and generally be consistent with each other. This is something that I already knew implicitly, but it helps so much to have this tension spelled out explicitly. I remember arguing for actively designing parts of the interface, for establishing guidelines, and having team members that tell you that it will either happen organically or that it does not matter enough.

    This explicit version shows pretty clearly that it is not going to happen organically: Everything about the way we develop software points in the opposite direction. If you want cohesion, consistency, and an integrated UX, you have to work for it. It is an uphill struggle and you have to actively put energy and work towards it.