Copy docs: коли тексти в інтерфейсі повні та послідовні, і як це підтримувати

Коротке резюме: copy docs (копі-доки) — це фреймворк, який дозволяє дизайнерам та розробникам продуктів розумно керувати своїми продуктовими текстами. У цій статті Валерія Паніна ділиться своїм досвідом того, як техніка copy docs кардинально змінила її робочий процес.

Пам'ятаєте, як часто вам доводилося множити фрейми в Figma чи Sketch, щоб продемонструвати зміну в одному реченні на екран? Чи то тинятися файлом .json у редакторі VS Code щоразу, коли потрібно було оновити текст отої кнопки? А як щодо помилок через відсутність плагінів для перевірки граматики в більшості графічних редакторів? Я не стану казати, що копі-доки — як і будь-який інший фреймворк, — це чарівна паличка, але ця техніка принаймні може спростити велику частину роботи.

Отже, розглянемо цю техніку детальніше.

Одне з перших публічних згадувань про copy docs належить Андреа Другай, тодішній UX-райтерці у Dropbox. Я познайомилась з цим методом під час сертифікації у UX Writing Hub Academy в 2019 році в Тель-Авіві.

Відтак,використовую copy docs як дизайнерка продуктів, і за два роки модифікувала його відповідно до потреб UX-спеціалістів в цілому, особливо в невеликих командах.

Це документ, де ви зберігаєте та оновлюєте всі тексти в інтерфейсі продукта, їх стани та описуєте їх поведінку.

За такого підходу Figma або Sketch є кінцевим джерелом елементів інтерфейсу, тоді як copy doc — кінцевим джерелом текстів інтерфейсу. У такому розділенні багато сенсу, оскільки ви використовуєте інструменти дизайну для проєктування та інструменти редагування для роботи з вмістом. Загалом, copy doc виводить на новий рівень процес роботи з текстами, як для фахівця з дизайну, так і для всієї команди.

Крім того, стає менше шансів пропустити «приховані» стани (підпис про помилку або про успіх під заповненим полем, тощо) й можна використовувати різні графічні засоби для анотацій. Також так простіше описувати складну логіку на кшталт «Якщо подія X трапляється ... тоді текст кнопки стає Y...» — ви буквально змінюєте лише текст, не взаємодіючи з графікою.

Тут ви можете заперечити, що робота з текстом поза інтерфейсом — це відривання від контексту, і що так важче влучити в необхідний розмір. Насправді в 9 випадках із 10 ви будете знати оптимальну довжину тексту. А щодо невизначених випадків, то завжи можна перевірити конкретний рядок вінтерфейсі, коли це дійсно потрібно.

Хоча у випадку з IELTS, чим більше синонімів ви використовуєте — тим краще, це не працює в UX. Наприклад, якщо ви використовуєте термін «Видалити» в своїх проектах для позначення дії з видалення елемента, але в певному місці з'являється «Стерти» для тієї ж дії, це може зпантеличити користувачів. Вони можуть подумати, що йдеться про якусь іншу дію.

А у копі-доку ви можете легко виділити всі випадки, де використовується певне слово. Це стає в пригоді, коли ви хочете перевірити себе або щось гуртом змінити. Скажімо, ви провели юзабіліті-тести та виявили, що у вашому випадку «стерти» підходить краще. Отже, ви швидко виконуєте масове перейменування й передати його розробникам чи йдете узгоджувати дизайн. Насправді, набато краще виправити термін в документі й тільки після того вже коригувати фрейми у Figma чи Sketch, аніж поспіхом повзати по них й вишукувати кожен потрібний елемент, аби нічого не пропустити.

Це працює й у інший бік теж: коли ви хочете розділити термін. Наприклад, спочатку в роботі із моїм власним черговим копі-доком я використовувала слово «коментар» для позначення двох різних ідей. У першому випадку я мала на увазі власний інструмент коментування від Google, а в іншому посилалася на свої уточнення-пояснення елементів документа. За суттю, ці «коментар» різні: перший передбачає «пінг-понг» дискусію з командою, а другий — мої інформаційні замітки для розробників щодо поведінки елемента. Тому тепер я використовую «коментарі» та «анотації» відповідно.

Більшість мовних спеціалістів, зазвичай, працюють у форматах, подібних до Word. А ще тут вони можуть зробити оцінку, базуючись на підрахунку слів.

Оскільки текстовий редактор надає прекрасний набір інструментів, призначених для роботи власне з текстом, то працювати й особливо співпрацювати з колегами — одне задоволення.

І я вже згадувала про переваги у розподілі завдань. Тепер, щоб оновити текст в «живих» (тобто вже реалізованих) елементах, ви ділитеся лише текстом — упорядкованим і анотованим.

Використовуючи фреймворк copy doc ви уникаєте дублювання, коли треба розмножувати фрейми в проєкті тільки через зміни у тексті. Зайве говорити, що це підвищує продуктивність.

Хіба ви не мрієте про це щоразу, коли набираєте рядок тексту в макетах Figma, Sketch або XD? Або коли побачили похибку у вивантаженому фреймі?..

Для початку роботи з copy docs вам потрібен скелет вашого інтерфейсу. Я вважаю за краще створювати copy doc на етапі макетів, але ви можете почати з етапу прототипування. Якщо ж ви дотримуєтесь підходу content-first, то можете навіть створити прототип, базуючись на copy doc, а потім використовувати його як список необхідних елементів під час проєктування UI.

Створіть розділи, які відповідатимуть назвам ваших екранів.
Фото: Застосуйте стилі та додайте зміст, щоб ви могли зручно рухатися документом.

Краще використовувати шаблон «Заголовок + Знімок екрана + Таблиця» для кожного фрейма.

Найкраще створити порожні таблиці з попередньо встановленими стилями під кожним скриншотом. Для цього створіть таблицю для першого екрана та заповніть її. Потім скопіюйте та вставте заповнену таблицю під другий знімок екрана, видаліть зміст, скопіюйте ще раз тепер вже порожню і вставте під решту скриншотів, скільки треба разів.

Все готово!

Працюйте екран за екраном. Почніть з просторів імен. Потім заповніть власне тексти інтерфейсних елементів, уникаючи поширених підводних каменів, про які я розкажу трохи нижче.

Загальний простір імен для елемента вмісту буде виглядати так:

Розділ / Підрозділ / Група /… / Пункт
Таблиця / Назва / 1-а колонка

Переконайтеся, що назви в документі відповідають назвам компонентів вашого інтерфейсу.

Назви компонентів ж, в свою чергу, повинні відповідати тому, як їх називатимуть ваші розробники. Якщо ви не впевнені, яку назву обрати, то краще проконсультуйтеся з ними.

Перебуваючи поза дизайн-редакторами, ви можете використовувати різноманітні графічні елементи для передавання сенсів, не піклуючись про вигляд вашого інтерфейсу.

Наприклад, використовуйте:

• Виділення змінних
  
• Дужки для анотації
  
• Emoji чи Unicode символи для станів
  

Будьте послідовними — використовуйте один і той же метод для виділення кожної відповідної події. Пам'ятаєте ж про узгодження?

Також не оминайте доступність та зручність: добре, коли різні елементи відрізняються за кількома параметрами.

Не використовуйте ідентичні строки повторно.

Наприклад, якщо у вас є екран із загальним заголовком і певними значеннями, вкажіть заголовок на початку розділу з цим екраном в першій таблиці, а потім в інших таблицях не згадуйте заголовок (що залишається тим самим) знову, а відображайте тільки елементи, що змінюються.

Зрозуміло, що назви та типи елементів можуть відрізнятися від проєкта до проєкта, але нижче наведено найбільш поширені, які ви можете використовувати й у себе.

Зворотній зв'язок (feedback): повідомлення, попередження, сповіщення тощо.

• Info
  
• Success
  
• Warning
  
• Error
  
  

Поля введення (inputs), тощо:

• Placeholder
  
• Typing
  
• Filled
  
• Null
  
• Various errors
  
  

Ви вхопили ідею.

Буквально використовуйте їх як контрольний список, щоб надати вичерпний вміст для кожної зміни стану елементів.

Що стосується зовнішнього вигляду, або створіть окремий рядок для кожної зміни чи ярлика, або згрупуйте їх в одній клітинці з примітками.

Змінні — це ті стрічки тексту, які змінюються залежно від контексту користування. Зазвичай це дата і час, імена користувачів, номери тощо.

Можливо, ви вже врахували їх на етапі інформаційної архітектури або, частково, в редакційній політиці. А тепер copy doc — це просто місце, де можна відобразити, які дані є постійними, а які змінюються залежно від контексту, та як саме.

Виділіть змінні і виберіть їх форму. Дотримуйтесь того ж правила контр-надмірності: вкажіть форму змінної один раз, бажано на початку, а потім посилайтеся на неї протягом документа.

Не забудьте подумати про мінімальні і максимальні значення кожної змінної — якщо ви помітили, що це якимось чином впливає на UI, ви можете залишити відповідну інструкцію.

Це майже все. Техніка copy doc потужно змінила мій робочий процес, і я буду рада, якщо поліпшить і ваш!

Я підготувала для вас шаблон. Отже, скопіюйте собі [Template] Copy doc — і користуйтеся!

— «У копі-доку ви можете легко виділити всі випадки, де використовується певне слово». Не могли б ви детальніше пояснити, як це зробити?

— Звичайно! Тут йдеться про нативну функцію google-документів «знайти та замінити».

Скажімо, ви вирішили всюди замінити «видалити» на «очистити». Щоб просто виділити та побачити кількість екземплярів цього слова, ви можете натиснути Command + F / Control + F й відкриється нативне вікно пошуку.

Якщо ви вирішите зробити групове перейменування, то можете натиснути Command + Shift + H / Control + Shift + H, і з'явиться меню «знайти та замінити».

Свіжий приклад того, коли я використовую цю функцію. У нашому продукті ми маємо звичайний процес реєстрації. Щоб зробити його бадьорішим я використала плейсхолдер «Джон Г. Ватсон» у полі для внесення імені. Потім вирішила змінити його на більш гендерно-нейтральний варіант «Джо Ватсон». Тому я просто зробила групову заміну на «Джо Ватсон» + пізніше, оновлюючи екрани Figma, виділила в копi-доку всі місця, де було це поле, щоб легко побачити, куди потрібно внести зміни.

— За свій досвід зі зрілим складним продуктом я можу навести багато прикладів, коли це спростило б життя усім. Але зараз я працюю «з нуля» над абсолютно новим продуктом. І з'явилося запитання — на якому етапі накладні витрати на такого рівня роботу з документами врівноважуються перевагами при потенціальному рості продукту та компанії? На вашу думку, набагато важче створити копі-док ретроспективно, ніж зробити це завчасно й будувати разом із самим продуктом?

— Хороше питання для роздумів. У мене була схожа ситуація.

Моя точка зору — якщо у вас вже є робочий продукт і ви хочете застосувати копі-док, то як на мене, краще не створювати повний документ з ретроспективою усіх текстів в інтерфейсі одразу. Натомість краще обрати певний аспект продукту (подумайте, від чого ви могли б отримувати найбільшу користь, якщо б мали для того копі-док) та зробити частковий копі-док.

Під «аспектом» я маю на увазі наступне.

Припустимо, у вашому продукті є багато різних повідомлень про помилки — тоді створіть копі-док, в якому будуть тільки такі повідомлення, але вичерпно, для кожного екрану.

Або, скажімо, у вас є багатоетапна форма з динамічними назвами полів введення (labels).

Отже, виберіть той аспект, де найбільше змінних і безліч умов.

Просто пам'ятайте, що копі-док має бути вичерпним — якщо він стосується повідомлень про помилки, то має містити всі такі повідомлення; якщо йдеться про маркери чи ярлики — тоді має бути вписаний кожен такий елемент.

Це те, що я тестувала, і воно дало хороший результат.

Пізніше, в ході розробки продукту, якщо ви побачите, що «повний» копі-док того вартує (тут якраз ваш досвід роботи зі скороченою версією допоможе прийняти обґрунтоване рішення), ви можете щодня приділяти якийсь час, щоб охопити й інші моменти.

І моя історія.

Якось у мене був проєкт, де я вирішила спробувати поєднання Airtables + JSON для управління текстом в інтерфейсах. Для того треба було дочекатися, поки розробник створить свою першу версію JSON, потім напише скрип аби імпортувати його в базу Airtables, після чого я заповню і доповню зміст, віддам знов розробнику аби він додав відсутні поля й експортував все в файл JSON знов (я дійсно спробувала безліч способів управління текстами в інтерфейсах :-). Якщо коротко, то це не спрацювало. Щодо продукту, на цьому етапі велика частина макета з текстами в інтерфейсах в Figma вже була готова, тому я зробила копі-док, який містив тільки повідомлення про помилки. Створення повного копі-док значно відклало б процес розробки, але цей обмежений документ був правильним рішенням.