Node 사용자 인터페이스 설계

n8n node UI 설계 가이드라인에 대한 레퍼런스 문서입니다.

대부분의 node는 API의 GUI(그래픽 사용자 인터페이스) 표현입니다. 인터페이스를 설계한다는 것은 API 엔드포인트와 파라미터를 사용자 친화적인 방식으로 표현하는 방법을 찾는 것을 의미합니다. 전체 API를 node의 양식 필드로 직접 변환하면 좋은 사용자 경험을 제공하지 못할 수 있습니다. 이 문서는 따라야 할 설계 지침과 표준을 제공합니다. 이 가이드라인은 n8n에서 사용하는 것과 동일합니다. 이는 커뮤니티 node와 내장 node를 혼용하는 사용자에게 원활하고 일관된 사용자 경험을 제공하는 데 도움이 됩니다. 설계 지침 # 모든 node는 n8n의 node UI 요소 를 사용하므로 색상, 테두리 등 스타일 세부 사항을 고려할 필요가 없습니다. 그러나 기본 설계 프로세스를 거치는 것은 여전히 유용합니다: 통합 중인 API 문서를 검토합니다. 스스로에게 다음을 물어보세요: 무엇을 생략할 수 있나요? 무엇을 단순화할 수 있나요? API의 어떤 부분이 혼란스럽나요? 사용자가 이해하는 데 어떻게 도울 수 있나요? 와이어프레임 도구를 사용하여 필드 레이아웃을 시험해 봅니다. node에 필드가 많고 혼란스러워지는 경우 필드 표시 및 숨기기 에 관한 n8n의 지침을 고려하세요. 표준 # UI 텍스트 스타일 # 요소 스타일 드롭다운 값 Title case 힌트 Sentence case 정보 박스 Sentence case. 한 문장 정보에는 마침표( . )를 사용하지 않습니다. 두 문장 이상이면 항상 마침표를 사용합니다. 이 필드에는 새 탭에서 열어야 하는 링크를 포함할 수 있습니다. Node 이름 Title case 파라미터 이름 Title case 부제목 Title case 툴팁 Sentence case. 한 문장 툴팁에는 마침표( . )를 사용하지 않습니다. 두 문장 이상이면 항상 마침표를 사용합니다. 이 필드에는 새 탭에서 열어야 하는 링크를 포함할 수 있습니다. UI 텍스트 용어 # node가 연결하는 서비스와 동일한 용어를 사용합니다. 예를 들어, Notion node는 Notion 블록을 Notion 단락이 아닌 블록이라고 불러야 합니다. Notion이 이 요소를 블록이라고 부르기 때문입니다. 이 규칙에는 예외가 있으며, 보통 기술 용어를 피하기 위한 것입니다(예: upsert 오퍼레이션 이름 및 설명 에 관한 지침 참고). 서비스가 API와 GUI에서 동일한 것에 대해 다른 용어를 사용하는 경우가 있습니다. 대부분의 사용자가 친숙한 것이므로 node에서는 GUI 언어를 사용합니다. 일부 사용자가 서비스의 API 문서를 참조해야 할 수 있다고 생각되면 힌트에 이 정보를 포함하는 것을 고려하세요. 더 간단한 대안이 있는 곳에 기술 용어를 사용하지 마세요. 이름 지정 시 일관성을 유지하세요. 예를 들어, directory 또는 folder 중 하나를 선택하고 그것을 고수하세요. Node 명명 규칙 # 규칙 올바름 잘못됨 node가 trigger node인 경우 표시 이름 끝에 공백과 함께 'Trigger'를 붙여야 합니다. Shopif