そうした手間もさることながら、「全部まとめてデータを与える」→「全部まとめてデータが返ってくる」というターンアラウンドの長さ、粒度の大きさ、そしてその「一回」のためのコストの高さが特徴的なポイントである。途中経過を見たり、途中で止めてやり直したりなどはあまりできない。すなわち、操作性の面でも、労力を含むコストの面でもインタラクティブ性がとても低かったのである。
しかも、他のユーザーが使っている間は、順番待ちをせねばならない。裏を返すと、使っている間は計算機の能力をフルに専有できるということであるが、待つ時間を考えるとあまりうれしくはないことが多いであろう。
今から思うととても「使いづらい」が、当時は「計算機とはそういうもの」であったので、気にする人は少なかったはずである。ましてや“UX”に相当する部分を考えた人はほとんどいなかったであろうが、当時の人たちの「感じ方」が想像できるだろうか。真っ先に改善すべきUX的な課題はどこにあると考えられるだろうか。
当時の限られた技術でどうそれを改善できるだろうか。現在でも、まとめてデータを与え、まとめて答えのデータが返ってくればいいような用途も多々あるが、必要に応じて途中の様子をモニタリングできることが多い。あなたが「そういうもの」と思って使っている・見ているシステムの中に、（解消可能なはずなのに）そのようなインタラクティブ性の低さを引きずっているものはないだろうか。
ちなみに当時も、計算機システムのようなものの延長線上にある可能性として、「memex」のようなコンセプトが考えられたりもしている (興味のある方は調べてみていただきたい)。夢想の度合いは高いが、使い方やUXに近い側からの発想とも言える。これは後のハイパーリンク、ひいては ワールドワイドウェブ（WWW）の登場へとつながっている。
ユーザーが待つ→ユーザーを待つ
時代が進むと、マルチタスク、マルチユーザーの機能が使えるようになり、「待つ」という課題がある程度解決した。計算機のコストが下がり、計算能力に余裕が出てくると、逆に、計算機がユーザーの入力を待ってくれるようになってきた。しかも、計算機は待っている間に裏でさまざまな作業ができる。
全部まとめて与える必要があった一連のプログラムやデータは、コマンドラインインターフェースで、細かいステップごとにやりとりできるようになった。あるコマンドの結果を確認して（場合によっては途中で止めて）次のコマンドを入力できるので、試行錯誤もしやすくなった。
