Clever Geek Handbook

UXとGTDを使用して記事を書く方法

すぐに予約する：これは記事の書き方に関する記事です。 ここでどちらの側からの削減も少し後で明らかになります。



多くの（確かにそれを持っています）定期的にいくつかのソフトウェア、プロジェクトのアイデア、ワークフローの改善などについての異なる意見を整理し、首尾一貫して述べたいという願望があります。 しかし、すべての欲求が完成した記事やプレゼンテーションに変わるわけではありません。 それで問題は何ですか？



これは次のように起こります。私はある種のトピックを理解しましたが、思考の定式化に問題はなく、多くの思考があります。 大まかな計画の概要を説明し、議論したいトピックのリストを作成し、インターネットを掘り下げ、12段落のテキストを書きます。 その過程で、新しいアイデアが熟します-あなたはそれらを計画に追加します。 翌日、さらにいくつかの段落を書き、計画を拡張および改良し、小さな本に似始めていることを理解します。 このような反復と熱意は2〜3回やや弱まり、見つかったリンクの束、計画されたトピックの3分の1をカバーする12段落または2段落、および未完成の作業感を残します。



もちろん、同僚、上司、またはさらに少ないクライアントを明日のプレゼンテーションに既に招待している場合は、可愛く終わります。 しかし、「うまくいく-ブログに投稿する、うまくいかない-致命的ではない」と考えて、魂のために書いた場合、「失敗する」リスクははるかに大きくなります。



叙情的な余談として、私は最近、「 UX 」ユーザーとの相互作用の設計と「 GTD 」の最後に物事をもたらすことに特に興味を持っていると言います。 それと別の両方-原則、アイデア、方法論、およびその哲学のクールな組み合わせ。



UXとGTDの観点からこの問題を消化した後に起こったことは次のとおりです。



柔軟な記事執筆のレシピ



  1. 計画：一般的な計画は機能しません。

    • 将来の記事を特定のパラグラフと個々の考えに分けて、それぞれ1〜3パラグラフで見ます。
    • アイテムをランク付けし、「メイン」のリストで最も重要で興味深いものの3〜7を選択します。 これは、あなたが今日書く「コア」記事になります。
    • 残りを「将来のために」リストに追加します。
  2. 書く：シンプルに始めましょう。

    • 「メイン」リストから簡単かつ簡単に考えを策定します。
    • 完璧を追求しないでください。 最初に記事の中核を作ります。 記事全体が目の前にあるときに、処方を理想に近づけることで気が散ることがあります。
    • たとえば、思考が大きくなり、説明が必要になった場合は、説明を後まで延期できるかどうか、または説明なしで記事の意味が失われるかどうかを調べます。 2番目のケースでは、どこにもアクセスできません。トピックを展開しますが、「メイン」の最後から「将来のために」リストに何かを移動します。
    • 記事が膨らまないようにしてください。 トピックがこれまでにない新しいアイデア、考え、説明を描く場合は、別の記事でハイライトします。
  3. 次は？

    • しかし、実際にはすべて。 メインリストのトピックが明らかになり、カーネルの準備が整いました。

      この瞬間にヒューズが通過したか、他のことに気を取られていたとしても、記事はすでにそこにあります-あなたは無駄にしようとしませんでした。 しかし、あなたが、ほとんどの優秀なプログラマーのように、定期的にかゆみを起こして最適化すれば、それを磨くことができます。
  4. 改善

    • 文の順序と段落の順序を見てください。 記事の主なアイデアは簡単にたどられますか？ 特定のポイントを明確にする必要はありませんか？
    • シンプルな言語を好む。 「無限」という単語を使用した場合（停止！段落を最後まで読んでください）、読者はその意味を見つけるために注意をそらす必要があります。 インターネットで迷子になるリスクに気を取られ、記事を忘れてしまいます。 （すべて、必要に応じて「無限」をグーグルで検索できますが、正直なところ何も面白いものはありません）。
    • 複雑な文章や大きな段落を避けてください。 長い文を分割または単純化します。
    • 書き方をチェック

      • 均一性：機密スタイルから学術的にドライなスタイルへの急激な移行は、読者を混乱させる可能性があります。
      • 飽和状態：大量の水と無関係な推論は、私たちの日々の狂気のリズムにうまく合いません。
      • 活気：画像とユーモアは技術的なテキストさえ害しません。 主なことは、過剰な塩分を使用しないことです。
    • 友達の記事をテストします。 読書中に誰かが眠りに落ちた場合、これは警告サインです。
    • もちろん、これらの推奨事項は成功への完全なレシピとはほど遠いものですが、記事を良好な状態に保ちます。 あなた自身がこの記事を気に入っている場合、または磨く予定の時間が過ぎて外で夜明けになっていることに気付いた場合、それは公開する時です。 あなたの本当の目標は、記事を書くことではなく、読者と共有することです。
  5. 継続

    • まだ多くの材料と熱意がある場合はどうなりますか？ 読者の反応を見て、「メイン」の「将来のために」リストから最も重要で興味深い考えを強調し、次の反復に進みます-2番目の部分を書きます。
    • 計画やアイデアは、記事に対する関心や視聴者の評価の変化とともに変化する可能性があることを忘れないでください。


  6. ^ Z
今このようなもの



GTDとUXに戻る



このレシピは何も思い出させませんか？ よく見ると、これはほとんど標準的なGTDシナリオです。必要なタスクのリストを作成し、大きすぎてサブタスクに分割し、緊急度/重要度に優先順位を付けて、最も優先度の高いタスクを完了します。 何が起こったのかを見て、残りのケースに優先順位を付け直し、優先度の低いケースを拒否または延期して、リストの最初の場所にある次のケースに進みます。



UXはどこから来たのですか？ 「ユーザーの特定の目標に焦点を当てる」設計原則の1つが機能しました。 出発点として、「ツール」-かなり抽象的なGTDアプローチがあり、効果的なアプリケーションのためにある程度の経験が必要です。 記事を作成するという目標を設定し、このように特定のコンテキストを設定すると、抽象的なアドバイスが具体的になり、アクションのガイドのようになりました。 さらに、主な目標は記事を書くことではなく、それを公開することであるという理解が得られました。 これにより、優先順位付けが改善されました。





アジャイル開発の原則の影響もここで明確に示されています：結果のレシピは、記事の反復作業を「サポート」し、ボリューム/機能を損なうことなく最終結果を得るためのタイムラインを優先し、「現在のリリース」に含めるものと延期するものを決定するのに役立ちます2番目のバージョン/部分に。



実際に、私のために働いた記事やプレゼンテーションを書くためのレシピを共有したいという欲求に加えて、目標＃2もありました。



あなたはそれがどれほど成功したかを判断します。


More articles:


All Articles