使用者的聲音
來自初期測試員的反饋
本頁面由日文原文機器翻譯而成。 閱讀日文原文
SimpleMemo，現在也在每天收到初期使用者、beta測試人員的反饋，繼續改善。 匿名收到的聲音按主題進行總結，總結了各自的對應和相關資訊。
App Store 公開評論
以下是App Store上公開的使用者評論。與本頁後半部的匿名測試版摘要不同，這裡引用的是實際發布的內容，並附上出處（App Store）連結；本語言版本的引文由日文原文機器翻譯。目前的綜合評分為★4.1（27則評分）。
輸入總之很順暢！
“使用記事本的時候，思考變得繁瑣，輸出時會出現下一個思考等，我認為使用時的動線很重要。 這個軟體真的很流暢，按下“傳送”按鈕的瞬間就會出現新畫面，所以希望只用過iPhone的預設軟體的人能使用。 像這樣不停的思考，能夠積極地思考和輸出，很難做到。 萬一想回頭的話，可以從履歷中搜尋，所以思考會更加順利，所以可以毫無顧忌地使用，這一點非常好。”
關於這個頁面
刊登的反饋，在beta測試及初期釋出期間，透過資訊和直接交流收到的感想、問題、要求，以個人不特定的形式總結、抽象化。 發言者的姓名、賬號、聯絡方式一概不包含。 如果從多人那裡收到類似傾向的聲音，作為主題彙總記錄。 回答和方針是收到各自聲音的當時（beta測試、初期釋出的時期）。 之後的變化都寫在了各個專案上。 現在預定的事情總結在公開路線圖中。
主題1：首次註冊・第一印象
📥 註冊、認證順利的聲音
“輸入郵箱地址收到驗證碼很快，感覺門檻很低”“認證郵件很快就收到了”的聲音。 最小化初始流的摩擦是設計上的首要事項，所以這裡的評價符合設計意圖。
⚡ “點選反應快”評價
收到了很多“操作感簡單”“傳送按鈕反應快”這樣的感想。 這是公稱值的啟動0.4秒（iPhone 16e・warm啟動的實際測量）・一鍵傳送這個數字，作為實際體驗可以感受到。 採用UIKit的實施上的判斷，在這裡起作用。
🔑 “一鍵識別”的體驗
收到了“特別是識別（認證）一鍵就能完成”的聲音。 在開啟應用程式的瞬間將筆記帶到可以開始書寫的狀態——我意識到儘可能不給這個路徑留下流程。
📥 “可以防止不寫”“也可以用於郵件草稿”
收到了“可以防止備忘錄被寫掉”“也可以作為郵件的草稿用”“即使刪除郵件也會留在應用程式內，所以很放心”的聲音。 備忘錄軟體即使寫字的瞬間很快，如果沒有以後訪問的路徑，就會變成單純的消費行為。 在本APP中，可以透過“自己的郵件收件箱”和“APP內履歷”的2個路徑進行回顧（在APP內履歷中留下的，從新的到100件）。
🚀 “在註冊周圍沒有猶豫，馬上就開始使用了”
收到了“在註冊周圍沒有猶豫，馬上就能開始使用”“整體上使用方便”這樣的感想。 傳送第一個1之前的導線是最重視的UX判斷之一。 因為每次增加設定畫面的選擇都會產生猶豫，所以當時的首次流程是縮小到“輸入郵箱地址→輸入驗證碼→備忘錄畫面”的3畫面，資料夾製作和設定的同意按鈕等，故意省略了後面返回的專案。“ 立刻開始使用”的反應，也是這種設計判斷發揮作用的證據。 （現在的應用程式，第一次啟動後會立即開啟備忘錄的畫面，第一次傳送備忘錄時會詢問收件人的郵箱地址。）
⏱ “從下載開始1分鐘以內，自動輸入驗證碼感動”
“下載應用程式→輸入郵箱→接收驗證碼→透過應用程式輸入→可以使用備忘錄，沒有錯誤1分鐘”“對自動輸入驗證碼感到感動”的報告。 認證碼輸入欄指定了iOS的AutoFill提示（textContentType: .oneTimeCode），所以iOS將郵件中收到的程式碼作為候選人時，可以從鍵盤上方點選輸入（是否成為候選人取決於iOS和郵件應用程式）。 雖然很樸素，但是第一次體驗“連複製貼上都不需要”可以感受到差異相當大的部分。 用馬克杯來說，雖然是把手的舒適感等細節，但透過測試人員的語言化，終於可以確信“這裡有效”。
🖥️ “iPhone↔可以作為其他終端的文字橋”
使用方法的發現：“從iPhone到Windows PC等其他終端的文字複製貼上環境很簡單，有可以使用的場景”這樣的感想。 在iPhone中備忘錄→傳送到自己的郵件→在PC的郵件中開啟並複製文字，這種流程作為“剪貼簿替代”加以利用的想法。
背景：Apple的Universal Clipboard只能在同一Apple ID下屬的終端之間執行，所以Windows / Linux / ChromeOS之間有剪貼簿的牆。 本軟體代替了“寫給自己的郵件”的簡單性，郵件本身就具有跨平臺性，所以最終“收到電子郵件的所有終端”成為複製目的地。 雖然在設計時沒有這麼明確地說明用途，但作為測試員獨自發現的使用方法，很有價值。活用事例 上追加討論中。
背景：Apple的Universal Clipboard只能在同一Apple ID下屬的終端之間執行，所以Windows / Linux / ChromeOS之間有剪貼簿的牆。 本軟體代替了“寫給自己的郵件”的簡單性，郵件本身就具有跨平臺性，所以最終“收到電子郵件的所有終端”成為複製目的地。 雖然在設計時沒有這麼明確地說明用途，但作為測試員獨自發現的使用方法，很有價值。活用事例 上追加討論中。
🌙 “晚上可以確認白天的想法，郵件基礎的優點”
使用方法的發現：“因為有一定要檢查郵箱的習慣，所以晚上睡覺前可以用郵件確認白天想到的事情”的聲音。 即使有不開啟備忘錄軟體的日子，每天都會看郵件 — 那個每天的動線搭載本身就是價值的場景。
與設計的聯絡：本應用程式將“寫給自己的郵件”固定在輸出目的地的理由之一，正是這個“疊加在已經透過的動線上”的想法。 不需要每天開啟應用程式，相反，思考的碎片會流入已經透過的郵件的路徑，所以不需要“回憶筆記的事實的成本”。活用事例集 也在考慮追加說明。
與設計的聯絡：本應用程式將“寫給自己的郵件”固定在輸出目的地的理由之一，正是這個“疊加在已經透過的動線上”的想法。 不需要每天開啟應用程式，相反，思考的碎片會流入已經透過的郵件的路徑，所以不需要“回憶筆記的事實的成本”。活用事例集 也在考慮追加說明。
🔗 “從郵件回到應用程式輸入驗證碼的按鈕給人留下了好印象”
感想：“在註冊周圍沒有猶豫的地方（用Google賬號註冊）”“從認證郵件開始回到應用程式輸入驗證碼的按鈕的好感度很高”的聲音。
背景：初次流程中容易絆倒的是“郵件中收到的驗證碼，回到應用程式手動輸入”的往返部分。 在本APP中，透過認證郵件內的按鈕回到應用程式，直到輸入程式碼，將畫面的來回和複製貼上最小化（與iOS的認證碼自動輸入一起減少第一次摩擦的設計）。“ 沒有猶豫”這種反應，是儘可能消除這種往返的設計判斷有效的證據。
背景：初次流程中容易絆倒的是“郵件中收到的驗證碼，回到應用程式手動輸入”的往返部分。 在本APP中，透過認證郵件內的按鈕回到應用程式，直到輸入程式碼，將畫面的來回和複製貼上最小化（與iOS的認證碼自動輸入一起減少第一次摩擦的設計）。“ 沒有猶豫”這種反應，是儘可能消除這種往返的設計判斷有效的證據。
主題2：注意到的點和對應
🔇 “有時候傳送音不響”
報告：有按傳送按鈕也不會發出聲音的情況。
確認：請確認終端的靜音模式和應用程式的傳送聲音設定。
確認傳送：僅憑有無聲音無法判斷郵件的到達。 請確認未傳送的狀態和收件人的收件箱。 聲音設定是 FAQ“可以關閉傳送聲音嗎？” 上註明了。
確認：請確認終端的靜音模式和應用程式的傳送聲音設定。
確認傳送：僅憑有無聲音無法判斷郵件的到達。 請確認未傳送的狀態和收件人的收件箱。 聲音設定是 FAQ“可以關閉傳送聲音嗎？” 上註明了。
📜 “使用規則頁面空白”
報告：開啟使用規則頁面的第一個顯示是純白的，在瀏覽器重新載入時顯示的情況。
當時的情況：在iOS的WebView中首次讀取時，有可能發生罕見的事件，正在確認再現。 已經確認透過重新讀取恢復。 如果有需要注意的地方 諮詢 告知。
當時的情況：在iOS的WebView中首次讀取時，有可能發生罕見的事件，正在確認再現。 已經確認透過重新讀取恢復。 如果有需要注意的地方 諮詢 告知。
🔍 “很難理解'只要搜尋就可以隨時返回'”
報告：初次歡迎時收到的備忘錄上寫著“搜尋的話隨時都可以回來”，但是搜尋功能是應用程式端還是郵件端猶豫不決，在應用程式內搜尋了。 此外，從郵件中收到的備忘錄中沒有返回應用程式的動線，也有人說發現郵件→應用程式沒有導線。
當時的設計：“搜尋”指的是郵件客戶端（Gmail/Apple Mail等的搜尋）。 本應用程式將角色縮小到“投入”，將“整理、搜尋”交給平時習慣使用的郵件客戶端的方針。
當時的對應：您指出表達容易引起誤解，這一點是對的，正在考慮將首次介紹的文字明確表示為“在您使用的郵件客戶端中搜尋”的形式進行改善。 應用內履歷一覽也作為回顧過去備忘錄的手段存在，但由於初次介紹的說明不足，所以也計劃一起改善。（ 之後，在完成第一次設定時，不再自動傳送引導的備忘錄，最初的1通知是自己寫好後傳送的形式。 在現在的應用程式中，除了可以透過郵件應用程式的搜尋來查詢傳送的備忘錄外，在歷史畫面的列表向下拉出的搜尋欄中，還可以透過關鍵詞搜尋歷史記錄中留下的最近的備忘錄。 ）詳情 常見問題 呀 郵件管理的訣竅 也請參考。
當時的設計：“搜尋”指的是郵件客戶端（Gmail/Apple Mail等的搜尋）。 本應用程式將角色縮小到“投入”，將“整理、搜尋”交給平時習慣使用的郵件客戶端的方針。
當時的對應：您指出表達容易引起誤解，這一點是對的，正在考慮將首次介紹的文字明確表示為“在您使用的郵件客戶端中搜尋”的形式進行改善。 應用內履歷一覽也作為回顧過去備忘錄的手段存在，但由於初次介紹的說明不足，所以也計劃一起改善。（ 之後，在完成第一次設定時，不再自動傳送引導的備忘錄，最初的1通知是自己寫好後傳送的形式。 在現在的應用程式中，除了可以透過郵件應用程式的搜尋來查詢傳送的備忘錄外，在歷史畫面的列表向下拉出的搜尋欄中，還可以透過關鍵詞搜尋歷史記錄中留下的最近的備忘錄。 ）詳情 常見問題 呀 郵件管理的訣竅 也請參考。
⌨️ “在註冊畫面中鍵盤上有時會隱藏輸入欄”
報告：在註冊畫面上點選郵箱位址列時，鍵盤上會隱藏輸入欄的情況。 試了幾次就看不見了，感覺顯示位置不穩定。
原因：iOS的鍵盤迴避邏輯（ScrollView的inset調整、SafeArea / keyboardLayoutGuide的約束）在對焦時不齊的原因。 活躍的輸入欄還殘留著潛入畫面下方的案例。
當時的對應預定：計劃在下一個次要更新中修復。 為了在對焦時對應的欄位一定會在鍵盤上，明確地對齊滾動動作的方針。（ 在之後的更新中，包括鍵盤高度後來發生變化的情況在內，修改了輸入欄不被隱藏。） 感謝您的報告。
原因：iOS的鍵盤迴避邏輯（ScrollView的inset調整、SafeArea / keyboardLayoutGuide的約束）在對焦時不齊的原因。 活躍的輸入欄還殘留著潛入畫面下方的案例。
當時的對應預定：計劃在下一個次要更新中修復。 為了在對焦時對應的欄位一定會在鍵盤上，明確地對齊滾動動作的方針。（ 在之後的更新中，包括鍵盤高度後來發生變化的情況在內，修改了輸入欄不被隱藏。） 感謝您的報告。
主題3：要求・未來方向
📨 “如何整理積攢的備忘錄”
問題：“把備忘錄發到郵件裡，1日10通·1月300通時整理的工具不是需要嗎？” 這樣的指出。 雖然投入得很快，但之後的整理是另外一個問題，確實如此。
當時的答案：“整理”特意放在應用程式方面，推薦Gmail過濾器、標籤、搜尋運算子、AI合作（Gemini/Apple Intelligence）等郵件客戶端功能完成的設計。 這些具體的活用方法 部落格：郵件管理的訣竅 和、相關的 活用事例集 請參考。
當時的答案：“整理”特意放在應用程式方面，推薦Gmail過濾器、標籤、搜尋運算子、AI合作（Gemini/Apple Intelligence）等郵件客戶端功能完成的設計。 這些具體的活用方法 部落格：郵件管理的訣竅 和、相關的 活用事例集 請參考。
🔗 “傳送到Obsidian等其他收件人”
要求：“如果連線到Obsidian的話，可以選擇傳送地址怎麼樣”的建議。
當時的想法：敢於維持“傳送到自己的郵件”的選擇。 理由是，如果增加選擇的話，就會產生“考慮送到哪裡的時間”，Captio本該丟棄的摩擦會回來。 另一方面，透過郵件匯入Obsidian和Notion的運用是完全可以實現的，這 部落格 呀 vs Obsidian的比較頁面 中提到。 之後，對應了Obsidian的保管庫的筆記的補充（傳送地址的郵箱地址現在也是1）。
當時的想法：敢於維持“傳送到自己的郵件”的選擇。 理由是，如果增加選擇的話，就會產生“考慮送到哪裡的時間”，Captio本該丟棄的摩擦會回來。 另一方面，透過郵件匯入Obsidian和Notion的運用是完全可以實現的，這 部落格 呀 vs Obsidian的比較頁面 中提到。 之後，對應了Obsidian的保管庫的筆記的補充（傳送地址的郵箱地址現在也是1）。
📋 “從履歷中複製部分”
要求：不僅有履歷一覽表中的“全文複製”，還有“部分複製”，作為AI聊天的用途不是很方便嗎？ 這樣的暗示。
當時的情況：和舊Captio一樣，只有全文的副本。 AI合作的使用案例是無法完全預想的，所以回答了加入路線圖的討論。（ 在現在的應用程式中，長按歷史記錄中已傳送的備忘錄，就會開啟共享表，可以複製全文，也可以傳遞給其他應用程式。） 如果有具體的使用場景和希望的規格 諮詢 開始分享。
當時的情況：和舊Captio一樣，只有全文的副本。 AI合作的使用案例是無法完全預想的，所以回答了加入路線圖的討論。（ 在現在的應用程式中，長按歷史記錄中已傳送的備忘錄，就會開啟共享表，可以複製全文，也可以傳遞給其他應用程式。） 如果有具體的使用場景和希望的規格 諮詢 開始分享。
💾 “不發郵件，留在應用程式內的Save按鈕”
要求：“沒有傳送郵件，只有在應用程式內留下備忘錄的功能，我會很高興”的聲音。 草稿和尚未確定傳送物件、時機的備忘錄，一旦可以儲存在應用程式中，會更方便。
當時的想法：正如您所說，如果有Save按鈕的動作的話，體驗會擴大。 當時的“備忘錄一定會透過郵件傳送給自己”的設計是為了保護Captio的核心體驗而做出的判斷，但是增加“不傳送的選項”應該不會矛盾。（ 之後，如果選擇Premium的“只儲存Obsidian”，就可以不傳送郵件，只留在Obsidian的保管庫中。） 回答了除了考慮路線圖之外，還要考慮UI的嵌入方法。 如果有希望的具體移動方式（保留備忘錄的圖示位置、之後傳送時的動線等） 諮詢 開始告訴我。
當時的想法：正如您所說，如果有Save按鈕的動作的話，體驗會擴大。 當時的“備忘錄一定會透過郵件傳送給自己”的設計是為了保護Captio的核心體驗而做出的判斷，但是增加“不傳送的選項”應該不會矛盾。（ 之後，如果選擇Premium的“只儲存Obsidian”，就可以不傳送郵件，只留在Obsidian的保管庫中。） 回答了除了考慮路線圖之外，還要考慮UI的嵌入方法。 如果有希望的具體移動方式（保留備忘錄的圖示位置、之後傳送時的動線等） 諮詢 開始告訴我。
✏️ “備忘錄1行想用粗體將標題和正文從視覺上分開”
💬 “把傳送地址變成Slack的頻道投稿用郵件會很有趣吧”
使用方法的建議：“如果將傳送地址設為Slack的頻道投稿用郵箱地址的話，Slack上會堆積備忘錄，這樣會比較好”這樣的想法。
答案：收件人1是符合現在設計的使用方法，但我們沒有嘗試過。 在Slack的付費計劃中，每個頻道都可以建立專用的郵箱地址，然後將收到的郵件釋出到頻道。 如果將本應用程式的收件人定為那個地址，備忘錄就會被投稿到那個頻道。 但是，因為收件人是用確認碼認證的，所以最初確認碼的郵件也會到達那個渠道。 因為包括這個認證的步驟都沒有確認動作，所以作為已經確認的使用方法沒有介紹。“ 整理交給郵件客戶端/其他工具”的設計（Theme 3的 傳送地址設為Obsidian怎麼樣？ 相同的系統）應用於Slack的例子。
注意事項：這個Slack的功能可以在付費計劃中使用，工作空間的所有者和管理員可能會限制可以使用的人。 設定方法 Slack的幫助 請確認。
答案：收件人1是符合現在設計的使用方法，但我們沒有嘗試過。 在Slack的付費計劃中，每個頻道都可以建立專用的郵箱地址，然後將收到的郵件釋出到頻道。 如果將本應用程式的收件人定為那個地址，備忘錄就會被投稿到那個頻道。 但是，因為收件人是用確認碼認證的，所以最初確認碼的郵件也會到達那個渠道。 因為包括這個認證的步驟都沒有確認動作，所以作為已經確認的使用方法沒有介紹。“ 整理交給郵件客戶端/其他工具”的設計（Theme 3的 傳送地址設為Obsidian怎麼樣？ 相同的系統）應用於Slack的例子。
注意事項：這個Slack的功能可以在付費計劃中使用，工作空間的所有者和管理員可能會限制可以使用的人。 設定方法 Slack的幫助 請確認。
🤖 “想要AI聊天的動線”
要求：“最近有寫備忘錄的話什麼都放進AI的習慣，所以想要交給AI的動線。 那個是成為收費功能，還是以後會加入，從現狀來看還不知道”這樣的聲音。
當時的答案：當時，本APP本身沒有AI功能（從2026年7月開始，設定Obsidian聯動的人開啟“自動新增AI標籤”時，終端內的AI會附加標題和標籤）。 傳遞給AI的方法是“透過郵件轉發、複製貼上到AI客戶端”或“從歷史記錄複製→貼上到ChatGPT / Claude / Gemini”的外部合作。 這個 部落格“AI和備忘錄應用程式的區別” 呀 ChatGPT 合作工作流程 也總結了。
當時的方針：與Theme 3的另一張卡片“從履歷中的部分複製”密切相關的要求，回答了AI合作的動線（從履歷中一鍵傳遞給AI，透過共享表等）在路線圖上進行討論（收費還是免費也未定）。（ 在現在的應用程式中，長按歷史記錄中已傳送的備忘錄，就會開啟共享表，從那裡可以傳遞給其他應用程式。） 如果有具體的使用案例（想給哪個AI，什麼怎麼給） 諮詢 開始告訴我。
當時的答案：當時，本APP本身沒有AI功能（從2026年7月開始，設定Obsidian聯動的人開啟“自動新增AI標籤”時，終端內的AI會附加標題和標籤）。 傳遞給AI的方法是“透過郵件轉發、複製貼上到AI客戶端”或“從歷史記錄複製→貼上到ChatGPT / Claude / Gemini”的外部合作。 這個 部落格“AI和備忘錄應用程式的區別” 呀 ChatGPT 合作工作流程 也總結了。
當時的方針：與Theme 3的另一張卡片“從履歷中的部分複製”密切相關的要求，回答了AI合作的動線（從履歷中一鍵傳遞給AI，透過共享表等）在路線圖上進行討論（收費還是免費也未定）。（ 在現在的應用程式中，長按歷史記錄中已傳送的備忘錄，就會開啟共享表，從那裡可以傳遞給其他應用程式。） 如果有具體的使用案例（想給哪個AI，什麼怎麼給） 諮詢 開始告訴我。
🔎 “想要應用內的履歷搜尋功能”
要求：“傳送的郵件作為履歷留下，以後回過頭來很珍貴。 如果能夠透過搜尋等簡單搜尋的話，使用起來的滿意度就會提高”的聲音。
當時的想法：最初是將“整理、搜尋”委託給郵件客戶端的設計（Gmail的搜尋運算子非常強大）。 但是，在應用程式內，想要當場回顧“自己寫的備忘錄一覽表”的需求作為另一個軸心，確實存在。 Theme 2的“很難理解'只要搜尋就可以隨時返回'”是welcome文言的故事，而這裡是 新增in-app的搜尋UI的要求。
當時的方針：回答是考慮在履歷一覽表中新增增量搜尋（標題+正文）。（ 之後，在履歷畫面上新增了搜尋欄。 向下拉選單就會出現，可以用關鍵詞搜尋記錄中留下的最近的備忘錄。） 如果有希望的具體規格（搜尋範圍、日期過濾器的有無等） 諮詢 開始告訴我。
當時的想法：最初是將“整理、搜尋”委託給郵件客戶端的設計（Gmail的搜尋運算子非常強大）。 但是，在應用程式內，想要當場回顧“自己寫的備忘錄一覽表”的需求作為另一個軸心，確實存在。 Theme 2的“很難理解'只要搜尋就可以隨時返回'”是welcome文言的故事，而這裡是 新增in-app的搜尋UI的要求。
當時的方針：回答是考慮在履歷一覽表中新增增量搜尋（標題+正文）。（ 之後，在履歷畫面上新增了搜尋欄。 向下拉選單就會出現，可以用關鍵詞搜尋記錄中留下的最近的備忘錄。） 如果有希望的具體規格（搜尋範圍、日期過濾器的有無等） 諮詢 開始告訴我。
🧭 “重新考慮一下傳送按鈕和設定圖示的配置？”
要求：收到了多位關於配置的指出。“ 傳送按鈕在鍵盤的正上方比右上角更容易按下（熟悉LINE和聊天類AI）“右上角放置設定，左上角只顯示履歷，這樣很容易理解每個入口”“設定圖示的位置瞬間會迷路”等，希望將操作導線簡單整理好，這個方向的建議。
當時的想法：雖然仿著舊Captio培養的“右上角=傳送”的心理模型，但近年來的聊天UI（Messenger、ChatGPT、Claude等）是 鍵盤正上方的傳送按鈕 是主流。 是根據使用者世代和平時使用的應用程式來劃分最佳解決方案的領域。 另一方面，很難找到設定圖示的指出與配置是不同的問題，有提高可視性的餘地。
當時的方針：（1）傳送按鈕位置的定製（右上角或鍵盤上），（2）左上角=履歷/右上角=設定的作用在視覺上明確化，2點，在保持外觀簡單的情況下進行討論。 如果有具體的喜好的話 諮詢 開始告訴我。
當時的想法：雖然仿著舊Captio培養的“右上角=傳送”的心理模型，但近年來的聊天UI（Messenger、ChatGPT、Claude等）是 鍵盤正上方的傳送按鈕 是主流。 是根據使用者世代和平時使用的應用程式來劃分最佳解決方案的領域。 另一方面，很難找到設定圖示的指出與配置是不同的問題，有提高可視性的餘地。
當時的方針：（1）傳送按鈕位置的定製（右上角或鍵盤上），（2）左上角=履歷/右上角=設定的作用在視覺上明確化，2點，在保持外觀簡單的情況下進行討論。 如果有具體的喜好的話 諮詢 開始告訴我。
📓 “也想用在日記：想要履歷的編輯和模板”
💴 “免費是每天3則。 收費使用的價值嗎？” 直率的聲音
指出：“免費的話，在每天最多3則這個限制中，有人付費使用嗎？ 那麼用其他備忘錄軟體可以嗎，這是坦率的感想”，收到了觸及價值核心的反饋。 非常感謝您的指出。
我們的想法：本應用程式的價值不是“備忘錄應用程式之間的功能比較”，將備忘錄作為“寫給自己的郵件”輸出本身。實際覺得有價值的使用者，使用方式如下：
・傳送到Gmail的話以後容易搜尋（用強大的搜尋運算子即時發掘過去的備忘錄）
・Gmail的星/過濾器自動化ToDo管理（收件箱直接成為任務管理）
・即使終端壞了，備忘錄也會留在雲端=自動備份（Apple備忘錄在iCloud上也一樣，但是郵件是獨立於應用程式的）
—這樣的“備忘錄單體應用程式”很難替代只有郵件基礎才有的優點。反過來，不使用這些整合功能的使用者往往用免費方案就足夠了，我們也會如實說明。
當時的方針：這個“為什麼是郵件/為什麼是收費”第一次看到就沒有傳達的點被當作課題，首頁和 活用事例・郵件管理的訣竅 中回答了加強具體優點的語言化。 非常感謝您的坦率反饋。
我們的想法：本應用程式的價值不是“備忘錄應用程式之間的功能比較”，將備忘錄作為“寫給自己的郵件”輸出本身。實際覺得有價值的使用者，使用方式如下：
・傳送到Gmail的話以後容易搜尋（用強大的搜尋運算子即時發掘過去的備忘錄）
・Gmail的星/過濾器自動化ToDo管理（收件箱直接成為任務管理）
・即使終端壞了，備忘錄也會留在雲端=自動備份（Apple備忘錄在iCloud上也一樣，但是郵件是獨立於應用程式的）
—這樣的“備忘錄單體應用程式”很難替代只有郵件基礎才有的優點。反過來，不使用這些整合功能的使用者往往用免費方案就足夠了，我們也會如實說明。
當時的方針：這個“為什麼是郵件/為什麼是收費”第一次看到就沒有傳達的點被當作課題，首頁和 活用事例・郵件管理的訣竅 中回答了加強具體優點的語言化。 非常感謝您的坦率反饋。
關於反饋的處理
在beta測試・初期釋出期收到的聲音，像本頁面一樣作為不明確個人的總結加以利用，反映在改善和FAQ・指南的強化上。 不會刊登直接引用或與傳送者特定相關的資訊。 如果不希望刊登您傳送的反饋，請隨時透過諮詢告知。 迅速修改、刪除相關部分。