AI와 디자인

AI와 디자인. “AI의 도움으로 디자인하기”와 “AI가 가미된 제품/서비스를 디자인하기”라는 두 측면이 있다.

AI의 도움으로 디자인하기

ToDo

AI가 가미된 제품/서비스 디자인

도구가 만들어내는 결과물이 아니라, 결과물을 만드는 과정에서의 경험이 가장 중요한 산출물인 경우가 있다. 이 경우 과도한 자동화는 오히려 단점일 수 있다. 참고: 과정에 담긴 가치

자동화는 인간의 단점을 보완하고 장점을 증강하는 방향으로 적용해야 한다. 내가 읽은 뉴스와 유사한 뉴스를 추천해주는 알고리즘은 단점(선택적 노출 편향)을 강화하는 방식이다.

자동화는 강화하는 피드백(Reinforcing feedback loop) 뿐 아니라 견제하는 피드백(Balancing feedback loop)도 제공해야 한다.

좋은 사례:

Publications

Books:

Papers:

각종 메모

  • 2023-12 병목
    • AI-인간으로 구성된 시스템에서 조만간 (어쩌면 지금도) 병목은 1) 인간이 의도 구체화하는 단계, 2) 인간의 의도를 AI에게 전달하는 단계(또는 채널), 3) AI의 응답을 인간에게 전달하는 단계(또는 채널), 4) AI의 응답을 인간이 이해하는 단계 등인 것 같다. 1)과 4)에 대한 문제는 언제나 있었고 AI가 있건 없건 꾸준히 계발을 해야할테고, 2)는 현재 “텍스트 입력”, “음성 입력”, “낙서” 등이 있는데 정교하지도 않고 효율적이지도 않다. 3)은 “텍스트 출력”, “음성 출력”, “이미지 출력” 등인데 역시나 정교하거나 효율적이지 않다.
    • 타입 시스템은 의도를 구체화하고 이를 표현하는 과정을 돕는 효과가 있다. 인간-AI 협업 루프에서 병목은 대체로 AI가 아니라 인간인데(명확한 사고, 간명한 표현, AI의 응답을 이해), 정적 타입이 병목을 줄이는 역할을 일부 할 수 있을 것 같다. 예를 들면 이런 시도: https://microsoft.github.io/TypeChat/
    • TypeChat 유사한 범주: https://github.com/dzhng/zod-gpt
    • Hoogle+ https://github.com/TyGuS/hoogle_plus
    • 버튼을 클릭한 후 “이걸 검정색으로 바꿔”라고 지시대명사를 쓰기. https://webstudio.is/
    • 2024-02 When Words Cannot Describe: Designing For AI Beyond Conversational Interfaces
  • 2023-12-12 - Designing for AI: Panel Notes by LukeW
    • Chat is a very flexible interface, people can define how they want to use it and when they want to use it. But it is a very direct interaction with the model itself. There’s few affordances to help people understand the capabilities and limitations they are interacting with.
    • Text is a very imprecise medium, it’s good for general direction but more controls are needed for specific use cases. In the future, we’ll have a lot more powerful interfaces to AI models.
  • 2023-12 - Google Gemini 데모. 즉석에서 UI를 만드는 방식
  • 2023-03 - Building humane UI with LMs
    • 현재 방식이 “Text-in / Text-out” 위주이지만 사실은 “Anything-you-can-turn-into-text in / Anything-you-can-create-from-text out” 방식이 가능하다는 주장.
    • 내 생각엔 현재 방식은 “Text-in / Text-out”보다는 “Natural language-in / natural language-out”이라고 해야 좀 더 정확한 것 같다. “Text-in / Text-out”은 전통적인 Unix CLI. LLM 덕분에 가능해진 “NL-in / NL-out” 방식의 장점은 (전통적 UNIX CLI에 비해) 컴포지션이 더 유연하다는 점. “Anything-you-can-turn-into-text in / Anything-you-can-create-from-text out” 방식은 자칫 유연한 컴포지션을 해칠 수 있겠다. Google Gemini 데모 중 즉석에서 UI를 만드는 방식은 결과로 만들어진 UI와 인터랙션을 할 수 있지만 “NL-in / NL-out”에 비해 컴포지션이 어려운 느낌이 든다.

Articles

2024 © ak