SLASH
SLASH
SLASH 24
SLASH 23
SLASH 22
SLASH 21
SIMPLICITY
SIMPLICITY
SIMPLICITY 24
SIMPLICITY 23
SIMPLICITY 21
구독하기
채용 바로가기
전체
개발
디자인
Tools Product Design
Simplicity24, 성공의 문을 여는 가장 평범한 질문
Simple Questions, Big Wins. 지난 11월, 뜨거운 관심과 호응 속에 성황리에 막을 연
의 숨겨진 비하인드 스토리를 전해드려요!
2024년 12월 4일 · 윤석원
꼭 제품을 만들어야할까?
사용자가 한명이라면? 주어진 시간이 얼마 없다면? 제품 없이도 임팩트를 만들었던 이야기를 들려드릴게요. 싸고 빠르게 목표 달성하는 방법 알려드릴게요. 구글 시트로 사용성을 검증해 개선된 상담 프로세스로 제품화하면서 대고객 컴도 개선해 효율적으로 상담 프로세를 개선한 이야기.
2024년 11월 12일· 양보람
보러가기
레퍼런스가 없는 제품은 어떻게 시작할까?
아무도 해본 적 없는 도메인, 누구도 정확히 모르는 복잡한 업무를 다룰 때 무엇에 집중해야 할까? 직접 법령 해석하며 끝까지 정책을 파고, 가장 최적화된 워크플로를 만든 이야기.
2024년 11월 12일· 양효정
보러가기
사용자의 실수, 디자이너가 어떻게 해결할까?
실수를 없애기 위한 위지윅 제품을 만들고, 제품의 유저를 개발자에서 PO로 바꾸고, 적용률 높이기 위해 설득한 이야기.
2024년 11월 12일· 한지유
보러가기
디자인만으로 해결할 수 없는 문제, 어떻게 할까?
‘내가 할 수 있는 게 있나?’ 그저 막막했던 순간, ‘내 역할’에서 벗어나니 그제야 문제를 해결할 실마리가 보였어요.
2024년 11월 12일· 강효정
보러가기
디자이너 없이 사용성을 지킬 수 있을까?
400개가 넘는 어드민 화면, 디자이너가 한장한장 그리는 게 옳은걸까? 개발 생산성 vs 사용성, 어떤 게 더 중요할까? 페이먼츠의 레거시 어드민 청산 과정에서 디자이너가 직접 디자인 하지 않고도 수백개 화면의 사용성을 챙길 수 있었던 방법에 대해 소개해 드릴게요.
2024년 11월 12일· 하승주
보러가기
어려운 기능, 꼭 설명해야 할까?
기능이 너무 복잡하고 개념이 생소해서 사용자가 이해하기 어려운 제품. 설명을 덕지덕지 붙이거나 가이드 문서로 설명하는 것 말고는 할 수 있는 게 없는걸까..? 쓰기 쉬운 데이터 분석 툴이 되기 위해 시도했던 여러 실험들, 그를 통해 얻은 인사이트를 공유드릴게요.
2024년 11월 12일· 김보명
보러가기
문화에 대한 문제까지 ux로 해결할 수 있을까?
너무 추상적이고 큰 문제를 어떻게 해결할지 막막하다면? 디자이너가 계속 드릴다운해서 문제와 해결책을 구체화하는 과정을 들려드릴게요. 제품으로 토스팀의 문화를 지킨다는 미션을 어떻게 달성해 나갔는지에 대한 이야기.
2024년 11월 12일· 이영민
보러가기
100% 자동화, 정말 좋은걸까?
자동화가 모든 문제를 해결하는 키가 될 수 있을까? 아니라면 어디까지 자동화해야 하는걸까? 적절한 지점까지 자동화를 적용해 유저 만족도와 효율을 모두 챙긴 이야기.
2024년 11월 12일· 한세희
보러가기
아무도 눈치채지 못한 문제까지 해결해야 할까?
사용자가 말한 문제만이 정말 문제의 전부일까? 기존의 제품은 고려하지 않았던, 유저 스스로도 몰랐던 문제를 디자이너가 찾아내 해결해낸 경험을 들려드릴게요. 제품 바깥에 있어 숨겨져있던 워크플로의 비효율 영역을 새롭게 발견해 효율화를 극대화한 이야기.
2024년 11월 12일· 박성경
보러가기
지표가 좋으면 UX도 좋은걸까?
지켜야 할 두가지 지표가 상충할 때 어떤 답을 찾아야 할까? 어느 한 쪽을 포기해야만 하는걸까? 상충하는 것처럼 보이는 CTR과 유저 만족도 사이에서 해결해야할 진짜 문제를 찾아간 과정을 들려드릴게요.
2024년 11월 12일· 이영진
보러가기
우선순위가 없을때 디자이너는 어떻게 해야할까?
들어오는 태스크를 그때그때 단건 처리하지 않고 전체 플로우 파악을 통해 유저가 진짜 원하는 바를 알아내고 유저가 원했던 것보다 더 나은 기능을 배포한 이야기 (비효율적이었던 작업 방식을 근본부터 파악하고 바꾸기)
2024년 11월 12일· 이지현
보러가기
레거시 제품을 버리고 CS 효율 높이기
새로운 서비스가 매일같이 생기고 또 사라지는 토스에서는 상담의 퀄리티만큼 시간과 속도도 중요하게 생각해요. 상담원 분들이 쓰는 레거시 제품을 청산해 상담 업무의 효율을 끌어올린 과정을 소개해 보려 해요.
2024년 8월 5일 · 박성경
업무용 툴, 내 동료가 정말 만족했나요?
토스의 데이터 직군이 매일 쓰는 서비스의 만족도를 1점 끌어올리기 위해 10개월간 집요하게 파고든 과정을 소개할게요.
2024년 7월 24일 · 한지유
송금할 때 은행 이름을 꼭 입력해야 할까요?
계좌번호를 입력하면 은행을 추천해주는 역발상으로 송금 UX를 송두리째 바꾼 이야기를 들려드릴게요.
2024년 1월 3일 · 이다윗
슬랙봇 디자인 101
슬랙봇 디자인을 잘 하려면 무엇을 알아야하는지 알려드릴게요.
2023년 8월 17일 · 강영화
토스 최초의 Product Designer(Tools)의 일하는 방식
토스팀에서 첫 Product Designer (Tools) 직무로 일하기 시작하면서 어떤 걸 배웠는지 알려드릴게요.
2023년 6월 20일 · 강영화
내 아이디어를 너무 믿지 마세요
너무 좋은 아이디어라고 생각해서 만들었는데 실제 유저들의 반응은 정반대였어요.
2023년 3월 28일 · 강효정
디자이너가 새로운 도메인을 빠르게 학습하는 법
토스는 일이 굉장히 빠르게 돌아가는 조직이에요. 저는 1년 반 동안 무려 4개의 새로운 분야를 학습해야 했어요. 이때 제가 쓴 방법들을 알려드릴게요.
2023년 3월 7일 · 김보명
문제 원인의 원인을 찾아서
좋은 해결책을 내기 위해서 제가 쓰는 방법은, 문제 원인의 원인을 찾는 거예요. 진짜 문제를 발견하면, 임팩트 있는 해결책을 생각해 낼 확률이 훨씬 높아지죠.
2023년 3월 2일 · 강효정
1
2
1
2
인기있는 글
프론트엔드 서비스 최적화? 토스에서는 '이렇게' 합니다! 모닥불 | EP.9
토스 프론트엔드 챕터
@use-funnel 개발기 #2: 기존 라이브러리를 어떻게 뜯어 고칠 것인가?
강민우
토스 프론트엔드 개발자들이 더 이상 문서를 찾지 않는 이유
한주연
최근 댓글
홈페이지
회사소개
채용
고객센터: 1599-4905 (24시간 연중무휴)
㈜비바리퍼블리카 Copyright © Viva Republica, Inc. All Rights Reserved.