[UX/스터디] 개밥먹기, 어떻게 하면 잘하는 겁니까?
3회차 UX 스터디
- 온라인으로 UX 스터디 하고있는데 벌써 3회차.
- 나는 지금 개발하는 서비스를 곧 테스트해볼 계획인데 일단 내부 테스트, 개밥먹기를 하게 되는것이 가까이 있는 테스크임.
- 그 개밥먹기를 하는데 바이어스를 어떻게 피하는게 좋을까. 어떻게하면 뻔하지않게 할 수 있을까, 조금 더 의미있는 시간이 될 수 있을까 고민이었고 이에 대해서 함께 이야기함.
- 가지고 있는 책들에는 별 도움되는 이야기는 없었어서 구글링 해봄.
- https://instabug.com/blog/the-risks-of-dogfooding-and-when-not-to-dogfood/
Bias
It is natural for your team to be biased towards the app they are building; after all, it is the sum of their hard work! This bias tends to get stronger the closer your dogfooders are to the app’s development. So, it pays to include teams that are a little less involved with development in your dogfooding program especially if you are a bigger company. However, following up with a beta test is the only sure way to get unbiased feedback before you launch to your users.
- 너무 당연한 말이잖아!
그런데 이런 문구도 있음
When to skip dogfooding
While dogfooding certainly offers enough benefits to outweigh the risks, it is best to avoid it altogether in some cases that are highly incompatible with dogfooding. In those cases, insisting on dogfooding your product will actually cause more harm than good by either, providing misleading feedback, affecting your team’s productivity, or both.
Specialized software
If you are developing an app that does a very specific or specialized job which you can’t use or adapt, dogfooding it will obviously produce little results. In fact, it will likely do more harm than good by wasting your time and providing you with irrelevant results that are at best useless and at worst misleading. For instance, if you are developing an app that helps doctors diagnose their patients quickly and accurately, you definitely shouldn’t dogfood it and try to diagnose patients. Unless you too are a doctor, of course.
Immature product
When you release a new app that is still at the MVP stage, it is very normal for it to lack many features that you might find useful. Your app might do a great job of covering its basic uses cases, but without some features that extend its functionality or increase its productivity, it can end up being more of an obstacle than a tool.
그래도 지금 만드는 서비스는, 우리 구성원들이 잘 써서 부가가치를(특허, 아이디어 발견, 제품개발 등)내도록 하는게 큰 목표 중 하나임. 각 분야의 전문가, 연구자들이 넓은 의미의 고객이긴하지만, 팀원들도 석, 박사 출신이기에.. 우리가 개밥먹는건 유효하다고 생각하는 입장.
https://www.parkersoftware.com/blog/are-you-eating-your-own-dog-food/
Taste the benefits
So, dogfooding is important, but what specifically does your company get out of it? The benefits of eating your own dog food spread surprisingly far throughout your organisation.
Product confidence
If it’s good enough for Rover and Fido, it’s good enough for you. Eating your own dog food adds authenticity to your marketing efforts. When you use your own software, you demonstrate that you have confidence in your products.
This not only promotes trust from your customers, but saves the potential damage control (and embarrassment) when customers start to question why you’re using a competitor’s product. Isn’t your product supposed to be superior? In other words, dogfooding puts your money where your mouth is.
Identify with customers
By eating your own dog food, you get first-hand experience of the way your customers view your product. Using your own software means that you can see clearly the customer pain points with your software.
Without using your own product, you don’t discover all the annoying little usability issues that your customers have to deal with. Nor do you get the rush of satisfaction from features that work excellently. So, dogfooding means you can identify with your customers better – making for better, more empathetic customer service.
Find bugs
A good way to find the bugs that are most likely to affect your customers is to be one of your customers. After all, real end users will typically find bugs that weren’t uncovered in the standard testing process. (It’s Murphy’s Law.)
To find your product’s faults, you need warts and all knowledge. Eating your own dog food, then, gives you an extra way to find bugs in your software and improve the quality of your product.
Encourage cooperation
Eating your own dog food can be eye-opening for development teams. Development is often detached, distant from the front-facing service and support teams. Programmers have their head in the code, and don’t have to deal with the end user.
But when you use your own software, you become the end user. You get to see what the user experience is like first-hand. This can lead to questions and cooperation between different teams. When everyone is experiencing the product as a user, it’s easier to get on the same page.
- 글들을 읽고 드는 생각은, 생각해본 액션플랜은
1. 버그만 잘 발견해도 만족스럽겠다.
2. UT 하듯이, 알려주지말고 스스로 탐색해보게끔, 그리고 떠오르는 생각들을 소리내어 표현할 수 있게 도와줘야겠다. ("어? 그거 어떻게 하셨어요?", "지금 어떤걸 해보려고 하세요?", "어떤 생각을 하고 계세요?")
3. 어떻게하면 우리의 목표를 이루는데 도움이 될지 물어봐야겠다. (특허, 아이디어 발견, 제품개발 등에 도움이 되려면 어떤 기능이 필요할까? 방식이 필요할까?)
