엇갈린 설명을 가리는 판단 기준
디자인과 개발이 따로 놀 때는 공통 요소의 표현 규칙, 화면 크기에 따른 배치 조건, 접근성 요구가 같은 기준으로 전달됐는지 점검해야 합니다. 어느 쪽의 잘못인지부터 따지기보다 병원이 두 담당자의 공동 설명을 듣고 중간 화면에서 함께 확인하는 방식으로 진행합니다. 완성 화면의 인상이 다르다는 말만으로는 디자인 의도가 전달되지 않았는지, 개발 조건 때문에 표현이 달라졌는지 가리기 어렵습니다.
병원 담당자는 엇갈린 설명을 화면 요소와 연결해 질문합니다. 디자인 담당자에게는 의도한 표현과 적용 조건을, 개발 담당자에게는 전달받은 기준과 구현한 조건을 설명해 달라고 요청합니다. 두 사람이 서로 다른 자료를 기준으로 답한다면 취향을 논의하기 전에 자료의 버전과 확정 여부부터 정리합니다.
| 엇갈린 요구 | 디자인 담당 설명 | 개발 담당 설명 | 병원이 합의할 기준 |
|---|---|---|---|
| 공통 버튼의 표현 | 같게 표현할 속성과 예외 | 반복 적용한 규칙과 개별 처리 | 공통 적용 대상과 예외 조건 |
| 좁은 화면의 배치 | 내용의 우선순위와 이동 의도 | 배치가 달라지는 화면 조건 | 유지할 내용과 배치 변경 조건 |
| 이용 상태의 표현 | 선택·오류 상태의 표현 의도 | 상태가 발생할 때의 처리 방식 | 상태별 설명과 확인 화면 |
| 접근성 요구의 반영 | 설계에 포함한 요구 | 구현할 내용과 평가 준비 | 반영 단계와 담당자의 제출 자료 |
같은 자료를 받았어도 조건을 서로 다르게 이해할 수 있습니다. 병원은 업체가 설명을 마친 뒤 합의한 내용을 짧은 문장으로 기재하고, 두 담당자가 그 문장에 동의하는지 묻습니다. 아직 결정하지 못한 내용은 확정 사항과 따로 기록하며, 병원 내부에서 결정할 내용인지 업체가 추가 설명할 내용인지 명시합니다.
공동 설명에 필요한 전달 자료
국가 디자인 시스템은 스타일을 시각적 일관성을 위한 규칙으로, 컴포넌트를 반복해서 사용하는 공통 요소로 설명합니다. 또한 디자인의 기본 요소를 코드로 정의하는 디자인 토큰을 소개합니다. 병원 업무에서는 업체가 어떤 방식으로 규칙을 구현하든 디자인 자료의 표현과 개발 적용 사이를 설명할 수 있는지가 판단 대상입니다.
병원은 완성된 시안 이미지와 함께 공통 요소의 설명, 적용할 화면 목록, 미정 사항을 요청합니다. 개발 담당자에게는 각 자료를 실제 작업에 어떻게 반영했는지 연결해서 설명하도록 요구합니다. 자료가 있다는 답만 받지 말고, 특정 요소를 선택했을 때 디자인 설명과 구현 내용을 함께 제시할 수 있는지 확인합니다.
전체 화면을 다시 설명하는 회의보다 해석이 엇갈린 요소를 중심으로 설명하는 회의가 적합합니다. 병원 담당자는 서로 다른 답을 받은 항목을 미리 보내고, 업체가 필요한 자료를 준비하도록 합니다. 이 과정에서는 수정 권리나 비용 책임을 판단하지 않고, 어떤 설명이 빠졌고 어떤 결정이 남았는지를 기록합니다.
공동 기준에서 중간 화면까지의 순서
실장은 병원 내부 의견을 모을 담당자를 정하고, 업체에는 디자인과 개발 설명을 함께 받을 일정을 요청합니다. 병원 담당자는 승인한 자료와 이후 변경 요청을 준비하고, 업체는 현재 작업에 적용한 자료를 준비합니다. 자료의 이름만 같고 내용이 다른 상황을 피하도록 수정일과 확정 상태도 함께 기재합니다.
- 공동 기준과 전달 자료를 정리합니다. 병원 담당자가 승인한 내용과 업체가 전달받은 내용을 대조하고, 빠진 설명은 해당 요소 옆에 기록합니다.
- 구현 조건과 담당자 설명을 연결합니다. 디자인 담당자는 표현 의도를 설명하고, 개발 담당자는 그 의도가 적용되는 조건과 아직 구현하지 않은 내용을 제시합니다.
- 중간 화면에서 공동 확인을 진행합니다. 병원 담당자가 합의한 조건을 요청하면 업체가 해당 상태를 재현하고, 해결되지 않은 항목의 담당자와 후속 자료를 정합니다.
반응형 웹 디자인 기본사항 안내는 미디어 쿼리로 화면 크기에 따라 다른 스타일을 적용할 수 있다고 설명합니다. 병원은 개발 전에 배치 변경 조건을 업체가 설명하도록 요청하고, 중간 화면에서 그 조건이 어떻게 적용됐는지 이어서 확인합니다. 넓은 화면과 좁은 화면의 이미지만 전달하는 경우에는 그 사이에서 배치가 어떻게 달라지는지도 설명받습니다.
화면 자료와 후속 담당자의 연결
공동 확인 기록에는 결과뿐 아니라 판단에 사용한 화면과 남은 결정을 함께 기재합니다. 디자인 담당자의 설명 자료와 개발 담당자의 재현 화면을 같은 항목에 연결하면, 후속 답변이 처음의 질문을 해결했는지 대조할 수 있습니다. 표에는 실제 제출된 자료를 기록하고, 아직 받지 못한 자료를 제출 완료로 처리하지 않습니다.
| 공동 확인 대상 | 업체가 제시할 화면·자료 | 남은 결정 | 담당자와 재확인 결과 |
|---|---|---|---|
| 반복되는 공통 요소 | 요소 설명과 적용된 중간 화면 | 개별 표현을 허용할 조건 | 설명 담당자와 적용 결과 |
| 화면 크기별 배치 | 배치 조건 설명과 크기 변경 화면 | 내용 순서와 배치 전환 조건 | 구현 담당자와 재현 결과 |
| 접근성 요구 | 설계 반영 내용과 평가 기록 | 추가 평가가 필요한 항목 | 반영·평가 담당자와 후속 결과 |
| 아직 구현하지 않은 상태 | 예정된 처리 설명과 현재 화면 | 구현 후 제출할 자료 | 처리 담당자와 제출 여부 |
다음 일정은 회의 날짜만 정하지 말고 업체가 무엇을 제출할지 함께 정합니다. 병원은 자료를 받은 뒤 해당 항목의 질문에 답이 생겼는지 판단하고, 설명만 보완된 경우와 화면까지 반영된 경우를 따로 기록합니다. 업체 답변에 병원의 선택이 필요하다면 담당자가 임의로 확정하지 않고 내부 결정권자에게 전달합니다.
접근성 반영과 평가 역할의 차이
접근성 요구를 전달할 사람과 구현할 사람, 평가할 사람은 역할에 따라 다를 수 있습니다. 업체가 접근성을 고려했다고 답하더라도 누구에게 어떤 업무를 맡겼는지 설명하지 못하면 후속 질문의 대상이 불명확합니다. 병원은 디자인 단계의 결정, 개발 단계의 반영, 평가 단계의 결과를 각각 누가 설명할지 요청합니다.
국제 웹 표준화 기구의 웹 접근성 이니셔티브는 프로젝트 초기와 개발 과정에서 접근성을 평가하도록 안내합니다. 하나의 평가 도구만으로 모든 접근성 지침의 충족 여부를 판단할 수 없으며, 지식을 갖춘 사람의 평가도 필요하다고 설명합니다. 업체의 자동 평가 결과만 전달받았다면 사람의 평가가 필요한 내용을 누가 맡는지 추가로 묻습니다.
병원이 요구할 것은 접근성 항목 전체에 대한 즉석 판정이 아니라 현재 단계에서 반영한 내용과 남은 평가의 설명입니다. 디자인 담당자가 의도한 이용 방식을 설명하면 개발 담당자는 이를 구현한 상태를 제시하고, 평가 담당자는 판단할 수 있는 범위를 밝히도록 합니다. 결과를 설명할 사람이 정해지지 않은 항목은 완료로 처리하지 않습니다.
설명 자료와 동작 화면의 구별
정지 이미지는 표현 의도를 전달하는 자료이지만 화면의 동작까지 입증하지는 못합니다. 버튼을 선택한 뒤의 상태나 화면 크기를 변경할 때의 배치가 쟁점이라면 업체가 동작하는 중간 화면을 제시해야 합니다. 병원 담당자는 이미지로 판단할 내용과 재현이 필요한 내용을 나누어 요청합니다.
중간 화면이 전체 구현의 완료를 뜻하는지도 업체에 묻습니다. 일부 요소만 구현한 화면이라면 현재 설명할 수 있는 내용과 이후 제출할 내용을 기록합니다. 아직 반영하지 않은 요소가 포함된 화면을 병원이 승인할 때는 승인한 대상을 명시해, 설명용 자료에 대한 동의가 전체 결과에 대한 동의로 해석되지 않도록 합니다.
담당자 교체 때의 설명 연속성
업체 담당자가 변경되면 새 담당자가 기존 합의의 이유까지 이해했는지 묻습니다. 최종 자료만 전달하면 조건을 결정한 이유나 보류한 선택이 빠질 수 있으므로, 이전 담당자가 남긴 질문과 답변도 인계 대상에 포함합니다. 병원은 새 담당자에게 해결되지 않은 항목을 설명하도록 요청하고, 인계 전후의 답이 다르면 재논의할 대상으로 기록합니다.
진행 중인 업무의 담당자 이름을 변경하는 것만으로 인계가 끝나지는 않습니다. 새 담당자가 다음 제출 자료와 병원 결정이 필요한 내용을 설명할 수 있을 때 후속 일정을 정합니다. 이미 합의한 내용을 다시 결정하자는 요청을 받으면 담당자 교체 때문인지 새로운 구현 조건 때문인지 이유를 묻습니다.
자주 묻는 질문
개발 담당자가 회의에 참석하기 어렵다면 어떻게 진행합니까?
업체에 개발 담당자의 서면 답변을 먼저 요청하고, 회의 중 새로 나온 기술 질문은 미답 항목으로 남깁니다. 다른 담당자가 추측으로 대신 답한 내용을 확정하지 않도록 답변 주체를 기재합니다. 이후 개발 담당자의 응답을 받은 뒤 필요한 항목만 추가 논의합니다.
병원 담당자가 개발 용어를 몰라도 협의할 수 있습니까?
코드의 이름을 이해하는 것보다 어떤 조건에서 화면이 달라지는지 설명받는 일이 우선입니다. 업체에 전문 용어와 함께 이용자가 경험할 변화도 설명해 달라고 요청합니다. 이해되지 않은 용어가 결정에 영향을 준다면 설명을 받은 후 병원의 의견을 전달합니다.
공동 회의에서 결론이 나지 않으면 무엇을 요청합니까?
의견을 다시 제출하라고만 요청하지 말고, 결론을 내리는 데 부족한 정보가 무엇인지 업체에 묻습니다. 기술 검토가 필요하면 검토할 질문을, 병원 결정이 필요하면 선택에 따른 차이를 요청합니다. 추가 정보의 제출 시점과 결정을 맡을 사람을 정한 뒤 회의를 마칩니다.
업체 내부 메시지를 병원이 모두 받아야 합니까?
내부 대화 전체를 전달받을 필요는 없습니다. 병원의 결정에 영향을 주는 변경 사항과 미해결 질문을 업체가 정리해 전달하도록 요청합니다. 내부 논의가 진행됐더라도 병원에 합의를 요청하지 않은 변경은 확정 여부를 별도로 물어야 합니다.
개발 도중 새로운 기술 제약이 드러나면 어떻게 합니까?
업체에 제약이 발생한 이유와 영향을 받는 요소, 가능한 대응 방향을 함께 설명하도록 요청합니다. 병원은 대응 방향마다 유지되는 내용과 달라지는 내용을 받은 뒤 선택합니다. 일정 등 추가 영향이 예상된다면 해당 내용을 별도 협의 항목으로 기록하고, 화면 설명과 섞어서 결론 내리지 않습니다.