변경 이력은 누구를 위한 글인가
서비스 화면의 메뉴를 개편하면 보통 공지나 변경 이력을 함께 올립니다. 그런데 이 글이 '일부 항목을 개선했습니다' 한 줄로 끝나면, 이용자는 무엇이 어디로 옮겨졌는지 알 수 없습니다. 반대로 개발 과정에서 쓰던 용어와 세부 작업을 길게 나열하면 읽는 사람은 지금 어느 메뉴를 눌러야 하는지 오히려 놓치게 됩니다. 변경 이력은 작업의 성과를 알리는 글이 아니라, 예전 경로를 기억하는 사람이 새 경로를 찾도록 돕는 안내문이라는 점을 먼저 정해 둘 필요가 있습니다.
이전 이름, 현재 이름, 위치를 한 줄에 담습니다
가장 읽기 쉬운 형식은 바뀐 항목마다 한 줄을 만들어 이전 이름, 현재 이름, 현재 위치를 차례로 적는 것입니다. 예를 들어 서비스 안내가 이용 안내로 바뀌었다면 그 사실과 함께 어느 메뉴 아래에 있는지를 쓰면 됩니다. 이름만 바뀐 것인지 기능이 새로 생긴 것인지도 나누어 적습니다.
실제 화면에서 확인할 수 있는 사실만 적어야 합니다. 제공되지 않는 기능을 새로 생긴 것처럼 쓰거나, 준비 중인 내용을 지금 이용할 수 있는 것처럼 표현하면 안 됩니다.
이력 문구를 쓸 때는 읽는 순서도 고려합니다. 제일 위에 지금 어디에서 찾을 수 있는지를 두고, 그 아래에 어떤 항목이 어떻게 바뀌었는지를 이어 적으면 급한 사람은 윗부분만 읽고도 목적을 이룰 수 있습니다. 변경 항목이 많다면 이용 빈도가 높은 메뉴부터 배치하고 나머지는 묶어서 정리합니다.
날짜와 함께 남겨야 뒤늦게 읽어도 헷갈리지 않습니다
변경 이력은 적용된 날짜와 짝을 이룰 때 힘을 가집니다. 개편 전에 올린 안내에 적힌 위치 설명은 개편 뒤의 구조와 맞지 않을 수 있기 때문입니다. 이력에 날짜가 있으면 어느 글이 개편 이전의 것인지 이용자도 담당자도 구분할 수 있습니다.
옛 주소를 직접 열었을 때 새 메뉴나 해당 안내로 이어지는지 시험해 보는 것도 이력 작성과 함께 해야 할 일입니다. 이력 한 편이 정확해도 연결이 끊겨 있으면 이용자는 다시 길을 잃습니다.
작은 표현 하나도 점검 대상입니다. '개선', '최적화', '리뉴얼'처럼 구체적인 내용을 담지 못하는 단어는 이용자에게 정보를 주지 못하므로, 실제로 바뀐 이름이나 위치를 대신 적는 편이 낫습니다.
화면에 보이는 말로 적고 내부 기록은 따로 둡니다
공개 문구는 이용자가 지금 눌러야 하는 메뉴 이름과 같은 말로 적습니다. 검토 과정, 디자인의 의도, 개발상의 이유는 운영 기록으로 남기되 공개 문구에서는 행동에 필요한 정보 정도로 줄입니다. 전문 용어를 꼭 써야 한다면 화면에 있는 메뉴 이름과 연결해 뜻을 짐작할 수 있게 해 줍니다.
화면 크기별 경로와 이미지 설명을 챙깁니다
휴대전화와 컴퓨터의 메뉴 구조가 다르다면 각각 어디에서 찾을 수 있는지 나누어 적어야 합니다. 새 화면을 캡처해 보여 준다면 이후 화면이 바뀌어도 이미지가 유효한지 살펴보고, 경로를 이미지 속에만 두지 말고 글자로도 남겨야 합니다. 처음 방문한 사람은 예전 메뉴를 알지 못하므로 현재의 경로만 읽어도 답을 찾을 수 있어야 합니다.
발행 후에는 문의의 변화를 지켜봅니다
이력을 공개한 뒤에도 같은 문의가 들어온다면 문장을 더 길게 쓰기보다 현재 메뉴의 이름과 위치가 충분히 눈에 띄는지 먼저 확인합니다. 이름이 이용자의 언어와 맞지 않거나 비슷한 항목이 여러 곳에 흩어져 있다면 이력 문구만으로는 해결되지 않습니다.
담당자가 바뀌더라도 같은 방식으로 작성할 수 있도록 이력 문구의 서식을 간단한 틀로 만들어 공유해 두면 좋습니다. 틀에는 이전 이름, 현재 이름, 위치, 적용 날짜, 확인한 사람의 다섯 칸이면 충분하고, 발행 전에 모든 칸이 채워졌는지만 보면 됩니다.
마무리: 이력은 과거를 현재로 이어 주는 다리입니다
변경 이력의 마지막 목적은 과거에 무엇을 했는지를 기록하는 데 있지 않고, 이용자가 현재 화면에서 필요한 페이지에 도달하게 하는 데 있습니다. 이전 이름과 현재 이름, 위치, 날짜의 네 가지를 빠뜨리지 않고 적는 습관을 들이면 개편 이후의 혼란이 줄어듭니다. 서비스마다 구조가 다르므로 공개 전에는 담당자가 실제 화면에서 경로를 따라가 확인하시기 바랍니다.