22. 버튼·입력칸과 화면의 변화
사용자의 행동에 반응하기
소개 페이지에서는 주로 글을 읽고 링크를 열었습니다. 기능이 있는 화면에서는 사용자의 행동에 따라 내용이 달라집니다. 검색어를 쓰면 목록이 줄고, 새 링크를 넣으면 항목이 늘어납니다. 이런 변화는 ‘행동 전 → 사용자의 행동 → 행동 후’로 나누어 생각하면 이해하기 쉽습니다.
예를 들어 별명을 입력하고 인사 버튼을 누르는 화면을 떠올려 봅시다. 처음에는 빈 입력칸과 안내 문장이 있습니다. 사용자가 ‘봄’을 적고 버튼을 누르면 ‘봄님, 반가워요’가 나옵니다. 화면에 어떤 정보를 가지고 있고, 어떤 행동으로 그것이 바뀌는지를 설명하면 AI가 만들 동작도 분명해집니다.
빈 화면에 필요한 서로 다른 안내
첫 링크를 추가해 보세요.
검색어를 지우거나 바꿔 보세요.
입력한 목록을 별도로 보관하세요.
첫 칸은 아직 자료를 넣지 않은 상태입니다. 사용자는 새 링크를 추가하면 됩니다. 둘째는 자료가 있더라도 현재 검색어와 맞는 항목이 없는 상태입니다. 검색어를 바꾸거나 지우는 행동이 필요합니다. 셋째는 화면에는 자료가 보일 수 있지만 다음에 남는다고 보장할 수 없는 저장 제한 상태입니다. 자료를 별도로 보관할 필요가 있습니다.
셋을 모두 ‘없음’이나 ‘오류’로 표시하면 사용자는 다음에 무엇을 해야 하는지 알기 어렵습니다. 현재 상태와 가능한 다음 행동을 함께 알려 주면 화면을 이해하기 쉽습니다. 이때 문장은 길 필요가 없습니다. 무엇이 일어났고 무엇을 할 수 있는지가 드러나면 됩니다.
AI에게 기능을 요청할 때 이런 상태를 예로 설명할 수 있습니다. 성공 화면만 만들게 하지 않고 빈 입력과 빈 결과, 저장 실패를 어떻게 안내할지 말합니다. 실제 실습에서는 해당 상태가 생기는 행동을 해 보고 문장이 맞게 나오는지 확인합니다. 모든 오류를 일부러 만들어야 한다는 뜻은 아니며, 확인하지 못한 상태는 따로 남깁니다.
상태에 맞는 안내는 자료를 지키는 데도 도움이 됩니다. 검색 결과가 없다는 이유로 전체 자료를 초기화하지 않고, 저장 제한을 알았으므로 중요한 목록을 별도로 보관할 수 있습니다. 문구를 다듬는 일이 기능과 무관한 장식만은 아니라는 것을 보여 주는 예입니다.
버튼과 링크가 맡는 일
링크는 다른 주소나 위치로 이동할 때 사용하고, 버튼은 현재 화면에서 작업을 실행할 때 주로 사용합니다. 모임 안내 페이지를 여는 것은 링크, 입력한 내용을 목록에 추가하는 것은 버튼으로 생각할 수 있습니다. 겉모습을 비슷하게 만들 수 있어도 사용자가 기대하는 동작은 다릅니다.
버튼의 글도 행동을 알려 줘야 합니다. ‘확인’보다 ‘링크 추가’가 무엇을 하는지 분명합니다. 자료를 지우는 버튼이라면 무엇을 지우는지 알 수 있어야 합니다. 화면의 모든 행동을 같은 이름으로 부르면 결과를 예상하기 어렵습니다.
입력칸에는 이름과 안내가 필요합니다
입력칸은 사용자가 정보를 적는 자리입니다. 이름, 주소, 검색어처럼 무엇을 넣는지 알려 주는 표시가 있어야 합니다. 칸 안에 옅게 보이는 예시는 입력하면 사라질 수 있으므로 입력칸의 이름까지 대신하지 않도록 합니다.
어떤 입력을 받을지도 정합니다. 링크 모음에서는 링크 이름과 웹 주소를 받아야 하고, 주소가 비어 있으면 저장하지 않아야 합니다. 이처럼 값이 조건에 맞는지 확인하는 일을 입력 검사라고 합니다. 어려운 기술이라기보다 실수했을 때 어떤 안내를 보여 줄지 정하는 일에서 출발합니다.
오류와 성공도 화면의 일부입니다
추가 버튼을 눌렀는데 아무 변화가 없으면 사용자는 눌렀는지조차 확신하기 어렵습니다. 항목이 목록에 나타나거나 ‘추가했습니다’라는 안내가 보여야 합니다. 실패했다면 이유와 다음 행동을 알려 줍니다. ‘오류’보다는 ‘웹 주소를 입력해 주세요’가 수정에 도움이 됩니다.
잘못 입력했다고 이미 쓴 내용을 모두 지울 필요는 없습니다. 주소만 빠졌다면 이름은 남겨 두고 주소를 채울 수 있게 하는 편이 자연스럽습니다. 사용자의 행동 앞뒤를 생각하면 성공 화면뿐 아니라 실수했을 때의 화면까지 구성할 수 있습니다.
화면의 상태를 구분하는 사례
목록 화면에는 적어도 ‘아직 항목이 없음’, ‘항목이 있음’, ‘검색 결과가 없음’, ‘저장할 수 없음’ 같은 상태가 있을 수 있습니다. 모두 비슷하게 비어 보일 수 있지만 의미는 다릅니다. 사용자가 다음에 할 일도 추가하기, 검색어 바꾸기, 보관 방식 확인하기로 달라집니다.
상태를 구분하지 않고 항상 ‘없음’만 보여 주면 원인을 알기 어렵습니다. 어떤 일을 했기 때문에 지금 화면이 되었는지 설명하는 문장이 필요합니다. AI에게 상태별 안내를 요청할 때도 이 차이를 말하면 됩니다. 오류 문구를 많이 만드는 것보다 사용자가 다음 행동을 이해하게 하는 것이 목적입니다.
입력과 버튼이 예상대로 작동하지 않을 때
입력은 그대로인데 결과가 바뀌지 않는 경우
인사 화면에서 별명을 바꿨는데 이전 인사가 계속 보인다면 언제 결과가 바뀌도록 정했는지 생각합니다. 글자를 입력할 때마다 바뀌는 방식일 수도 있고, 인사 버튼을 눌러야 바뀌는 방식일 수도 있습니다. 두 방식 모두 가능하지만 사용자가 예상할 수 있는 안내가 필요합니다. ‘입력 후 인사 버튼을 눌러 주세요’라는 문장 하나가 동작을 이해하는 데 도움이 될 수 있습니다.
링크 모음에서도 검색은 입력하는 즉시 적용하고, 새 항목 추가는 버튼을 눌렀을 때만 하도록 정할 수 있습니다. 이런 차이를 정하지 않으면 입력 도중 불완전한 항목이 생기거나 사용자가 버튼을 여러 번 누를 수 있습니다. AI에게 화면의 생김새뿐 아니라 어떤 행동을 기준으로 작업을 시작하는지 알려 주는 이유입니다.
버튼 하나에도 정할 규칙이 있습니다
‘링크 추가’ 버튼을 그려 놓으면 기능이 있는 것처럼 보입니다. 하지만 무엇을 읽고 어떤 조건에서 추가하는지 정하지 않으면 기대한 결과가 나오지 않을 수 있습니다. 이름과 주소가 모두 있어야 하는지, 주소가 틀리면 어떻게 알릴지, 추가 후 입력칸을 비울지 정해야 합니다. 버튼 모양은 그 규칙을 시작하는 입구입니다.
사용자의 행동을 순서로 풀면 필요한 조건이 보입니다. 이름 입력, 주소 입력, 추가 누르기, 결과 확인의 흐름입니다. 각 단계에서 멈출 수 있는 이유를 생각하면 빈칸 안내와 잘못된 주소 처리도 자연스럽게 이어집니다. 처음부터 복잡한 기술 용어를 쓰지 않아도 동작의 규칙을 설명할 수 있습니다.
성공했다는 신호를 고르기
항목을 추가했을 때 목록이 즉시 늘어나면 성공을 눈으로 볼 수 있습니다. 입력칸이 비워지는 것도 단서가 될 수 있지만, 그것만으로는 자료가 추가되었는지 모를 수 있습니다. ‘추가했습니다’라는 짧은 안내와 새 항목의 표시를 함께 사용할 수 있습니다.
반대로 실패했을 때 입력칸을 모두 비워 버리면 다시 작성해야 합니다. 주소만 잘못되었다면 이름은 남기고 주소를 고칠 수 있게 하는 방식이 자연스럽습니다. 성공과 실패에서 화면이 어떻게 달라져야 하는지 정하면 사용자가 반복해서 버튼을 누르는 혼란도 줄일 수 있습니다.
삭제와 초기화는 같은 말이 아닙니다
한 항목 삭제와 전체 목록 초기화는 영향 범위가 다릅니다. 버튼 이름이 ‘삭제’라고만 되어 있으면 무엇이 없어지는지 알기 어려울 수 있습니다. ‘이 링크 삭제’와 ‘전체 목록 비우기’를 구분하고, 중요한 자료를 지우는 동작에는 대상을 알 수 있게 해야 합니다.
첫 프로젝트에서는 전체 자료를 없애는 기능이 꼭 필요하지 않을 수 있습니다. 예시를 처음 상태로 돌리는 기능을 넣더라도 현재 입력한 자료가 사라진다는 점을 설명해야 합니다. 편리한 버튼을 추가하는 것과 되돌릴 수 있는 방법을 마련하는 일을 함께 생각합니다.
“버튼을 두 번 눌렀더니 항목이 두 개 생겨도 괜찮나요?”
원하는 규칙에 따라 다릅니다. 같은 주소를 중복 추가하지 않기로 했다면 두 번째 클릭에서 안내하고 목록은 그대로 두어야 합니다. 버튼을 여러 번 누르는 상황은 사용자가 한 번의 반응을 못 보았거나 처리가 늦다고 느낄 때도 생길 수 있습니다. 성공과 처리 상태를 알려 주는 이유입니다.
첫 링크 모음에서는 동일한 주소가 이미 있으면 추가하지 않는 규칙을 사용합니다. 새 항목이 보이고 성공 안내가 나오면 사용자가 다시 누를 이유도 줄어듭니다. 단순히 버튼을 예쁘게 꾸미는 것보다 행동과 피드백의 관계를 정하는 것이 중요합니다.
여러 사람이나 외부 서비스가 관련된 큰 작업에서는 중복 처리 문제가 더 복잡해질 수 있습니다. 실제 결제나 예약을 만드는 경우에는 별도의 설계와 검토가 필요합니다. 이번 실습의 작은 중복 검사가 모든 상황의 중복 처리를 해결한다고 생각하지 않습니다. 현재 범위에서 정한 규칙을 확인하는 것입니다.
꼭 기억하세요
기능은 버튼을 그리는 것에서 끝나지 않습니다. 행동 전후의 변화와 성공·실패 안내까지 정해야 합니다.