Redesigning the UX or API of a product seems to always be in the plans. No product is perfect and customer feedback abounds. Some things you might think of if you embark on such a journey.
Great list, as mentioned borne through hard experiences.
I remember the "good old days" of the Office "10 foot test". Each release we felt it necessary to make it obvious from 10 feet away that this was the "new and improved" Office.
I also wonder if this is a knowledge thing (something you can teach others so they can avoid) or a wisdom thing (no matter how many times you warn someone they do it anyway). I've seen so many teams and apps over the years make the same mistake, I start to think it's wisdom. They simply have to touch the stove to confirm it is hot like you told them
The 10' test is a really good one. I left it off though because it is often abused and used to justify a "refresh" or worse. the crazy Nokia 3600 (?) was that odd round phone that came out just as we were working on the start of the release and I remember vividly how it was "design for design's sake" which overtook Nokia. The 10' test was a part of that I think.
My sense is that this just needs to be experienced. Of course even experienced people mess this up too.
These are all great points. I used to be a graphic designer before getting into engineering, and during my junior-ship I butted heads with managers about small "improvements" we could make to the UI to streamline things, without taking into consideration a lot of the things you listed.
Often times, I'd get so caught up with thinking I was trying to improve our product, but in reality it was just minor things that kinda bothered me that our customers never once complained about. In fact, none of our customer complaints are EVER about the UI, because as long as the software is easy to use and it works just fine, then they have no reason to complain.
Now that I'm more of a mid-level engineer I understand a lot better. Any changes to the UI need to be REAL quality-of-life improvements, otherwise we're going to just waste time retraining customers to relearn how to use software, when the entire point of our product was to save them time in the first place.
Such a great list. As I read through each item, my internal-technologist-monologue was coming up with reasons why changes like these are still justifiable whilst simultaneously my internal-user-monlogue was yelling, "Yes! This! Listen to him!" and nodding its head so vigorously it fell off.
I love Kevin's comment - this is such a "still need to touch the stove" kind of acquired wisdom. You learn this kind of thing after earning the scars from ignoring your internal-user-monlogue and doing them regardless. You can feel Steven's scars coming through in each item!
Great list, as mentioned borne through hard experiences.
I remember the "good old days" of the Office "10 foot test". Each release we felt it necessary to make it obvious from 10 feet away that this was the "new and improved" Office.
I also wonder if this is a knowledge thing (something you can teach others so they can avoid) or a wisdom thing (no matter how many times you warn someone they do it anyway). I've seen so many teams and apps over the years make the same mistake, I start to think it's wisdom. They simply have to touch the stove to confirm it is hot like you told them
The 10' test is a really good one. I left it off though because it is often abused and used to justify a "refresh" or worse. the crazy Nokia 3600 (?) was that odd round phone that came out just as we were working on the start of the release and I remember vividly how it was "design for design's sake" which overtook Nokia. The 10' test was a part of that I think.
My sense is that this just needs to be experienced. Of course even experienced people mess this up too.
thank you for the note Kevin!
I believe it was Nokia 3650, just in case somebody was interested: https://www.buymobiles.net/blog/nokia-mobile-phones-you-cannot-believe-existed/
These are all great points. I used to be a graphic designer before getting into engineering, and during my junior-ship I butted heads with managers about small "improvements" we could make to the UI to streamline things, without taking into consideration a lot of the things you listed.
Often times, I'd get so caught up with thinking I was trying to improve our product, but in reality it was just minor things that kinda bothered me that our customers never once complained about. In fact, none of our customer complaints are EVER about the UI, because as long as the software is easy to use and it works just fine, then they have no reason to complain.
Now that I'm more of a mid-level engineer I understand a lot better. Any changes to the UI need to be REAL quality-of-life improvements, otherwise we're going to just waste time retraining customers to relearn how to use software, when the entire point of our product was to save them time in the first place.
Such a great list. As I read through each item, my internal-technologist-monologue was coming up with reasons why changes like these are still justifiable whilst simultaneously my internal-user-monlogue was yelling, "Yes! This! Listen to him!" and nodding its head so vigorously it fell off.
I love Kevin's comment - this is such a "still need to touch the stove" kind of acquired wisdom. You learn this kind of thing after earning the scars from ignoring your internal-user-monlogue and doing them regardless. You can feel Steven's scars coming through in each item!
So true! thank you.