Look at the picture above. We all are trained to think like a user (seeker, for this post). So, we know that they seek the shortest or quickest path to the resolution. The information that goes into troubleshooting is, therefore, either or both shortest and quickest. We help them clear the obstacles for we can hear them say, “I want to get through this thing.” Still, our aim is not to fix their problems, which is what brings me to the key thought here: troubleshooting isn’t always required.
上の図を見てください。 我々はすべて利用者のように考える訓練をされています。（探求者、この投稿では） それで、我々は 彼らが解決に最も短いか、あるいは最も速い経路を探すことを知っています。障害探索を始める情報は、従って、最短か最速かいずれかあるいは両方です。 我々は彼らが障害をクリアするのを手伝います、なぜなら我々は彼らが「私はこれを切り抜けることを望みます。」と、言うのを聞くことができるからです。 それでも、我々の目的は彼らの問題を直すことではありません、そしてそれは私をここの鍵となる考え：トラブルシューティングが常に必要とされるわけではないということに至らせることです。
It is a lot easier for the seekers to find the required information if it is organized, grouped within topics — especially so when they have time on their side. What one may need may not necessarily be from the same topic but organizing information within topics still improves findability. The problem with this approach is that our products are usually bundled with lots of functionalities and interoperable tools. It is then possible for a seeker to begin with finding the information (for example, in a WebHelp) for functionality A and end up with the resolution for functionality B. This is why we also occasionally implement the concept of User Persona-based writing.
もしそれがトピックの中で組織化されて、まとめられるなら、探求者が必要情報を見いだすことはずっとより容易です － 特に彼らが彼らの側に時間あるときはそうです。 人が必要とするかもしれないものは必ずしも同じトピックからではないかもしれません、しかしトピックの中で情報を整理することはなお 発見可能性を改善します。 このアプローチにおける問題は我々の成果が通常たくさんの機能性と相互運用可能な手段とつながっているということです。 その時探求者が機能性Ａのために（例えば、 WebHelp で）情報を見いだすことから始めて、そして機能性Ｂのための解決で終わることは可能です。 これは我々が同じく時折利用者ペルソナベースの執筆思想を実行する理由です。
===========================================================
============================================================
============================================================
