こうした質問については、あれもあるこれもあるといった一般論にならざるをえない（また個別の事例についても外部からはよくわからないので憶測しかできない）ということをご承知いただいた上で答えると、だいたい次のようなことが多いだろうと思います。なお回答内の具体例に見えるものは私の想像の産物であり、現実にあったことではありません。

まず質問されている事象について答えるなら、ユーザーへのインタビューや調査といったことをベースにすることはあまりないと思います。あるとしてもかなり間接的な影響のことが多いのではないでしょうか。

それよりも、製品（質問ではOSのUI）が提供したい情報の構造に現状との不一致があったり、おかしなことになっているという設計上の課題があり、それを解決するためにUIが刷新せざるをえないということがあったりするのではないかと思います。

たとえば、通知システムを利用して音楽アプリのコントロールなどをできるような仕組みがあるけど、本来の通知的な用途と混在してわけがわからなくなってしまっているといった現状があり、それを解決するためにAPIを改善し、そのあたらしい構造にそってUIも作り変えられる、といったことがあったりするでしょう。

こういう現状認識がどのようにして起こるかと言うと、第一には作っている人からすると当然の課題であったりすることも多いのですね。また、自社の提供するフィードバックシステムから集約される知見であったり、各種の記事、ユーザのコメント、様々なコミュニティでの質問などが参考にされることがあるでしょう。ユーザー調査によるproactiveな情報収集の結果が援用されることもありますが、そこまで多くないのではないかな、と思っています。

また美的な感覚の変化を反映するという面もあるでしょう。かつての事例ではスキューモリズムからフラットデザインへの変遷が大きいですね。ただそのときも、ただ単なる美的感覚だけでの選択ではなく、どのような利点があるか、使いやすさを損なわないのはどんなものか、という話もありますし、一方で全体としての統一性を生み出すための仕組みも考えられているはずです。ただたんに他のUIを真似するのではなくて、なんらかのメタファーやモチーフ、コンセプトを裏に設けることで全体の統一性をはかるといったことです。たとえばフラットデザイン化するときに、透明な画面の板が重なったような画面構成だとか、紙のデザインをイメージして、とかそういったコンセプトを打ち出しておき、そこから派生する形で個別のUI部品を作ることで見た目や使い心地の統一感がえられるというわけです。当然、過去のメタファー・コンセプトとは異なるため、見た目も大きく変わり、情報構造の多くが変化することはあります。

また、コンウェイの法則による影響やその打破を目指すといったこともよくあるのではないでしょうか。コンウェイの法則というのは、製品の構造が組織の構造を反映しているというものです。もとはコンピュータハードウェアで言われていたもので、買ってきたコンピュータの蓋を開けて中を見ると、そのコンポーネントの分割や配線構造から社内の組織構造が透けて見えるといった揶揄を意味していましたが、現在ではソフトウェア製品でもよく言われ、また残念ながら非常によく見られる話です。

たとえば、部署aと部署bがそれぞれ機能Aと機能Bを開発しているとして、それぞれが別々の画面になっていて、それぞれの機能の設定もそれぞれの画面からアクセスするような仕組みになっていたり、統合的な設定コンソールでも、分類が「部署aの担当するものの設定項目」と「部署bの設定項目」でカテゴリ分けされているなどしており、ユーザからは全く直感的ではない分類になっているといったことがあったりします。

甚だしい場合には、組織改編の結果としてこういう構造が再変化したりすることもあるでしょうし、そこまでではなくても「メジャーアップデート」に際して最新の組織構造に対応して変わってしまうということはありえます。

逆にコンウェイの法則はよく知られているので、そのような現状を問題視して、組織構造にとらわれずにより適切な情報構造を対応した階層構造をとるべきだ、という変化が起こることもあります。これは基本的にはよいことのはずですが、結果として起こるのは抜本的な大変化なので、既存ユーザからはなにがどこに行ったのか分かりづらくなってしまう、ということもあるでしょう。

ほかにもいろいろなことは言えるでしょうし、もっとしょうもない話もいろいろあると思いますが、だいたいにおいてはこのような、各種の変化に対応するための変化であったり、新しいコンセプトのためであったり、ゼロベースで見直した結果であったたり、といったことがもとだと思います。