{"id":978,"date":"2010-07-26T17:45:55","date_gmt":"2010-07-26T16:45:55","guid":{"rendered":"http:\/\/www.stevebromley.com\/blog\/?p=978"},"modified":"2019-11-06T17:45:02","modified_gmt":"2019-11-06T16:45:02","slug":"test-with-real-users-not-your-team","status":"publish","type":"post","link":"https:\/\/www.stevebromley.com\/blog\/2010\/07\/26\/test-with-real-users-not-your-team\/","title":{"rendered":"Test with real users \u2013 not your team"},"content":{"rendered":"

‘Free pizza and coke! Just play our game for an hour\u2019. Sounds like a good deal right? And pretty easy to organise, just pulling kids of the street. It can even be done in the pub, for mobile devices. Even this \u2018free pizza\u2019 recruitment is better than testing your game (or website, or application) with people from within your office. But why?<\/p>\n

Game development teams need a constant supply of fresh users to test the \u2018new user\u2019 experience with. I\u2019ve seen teams keep their project secret from their colleagues, not for official reasons, but so their colleagues can be tested as \u2018new users\u2019. Other teams test their games with their HR and secretarial staff, since they are unlikely to have had much exposure to the game.<\/p>\n

However it\u2019s a good guideline to never test with your team (unless of course you are building something for them). It\u2019s understandable why this situation arises \u2013 often budgets are too tight for intensive user testing, forcing teams to perform ad-hoc tests with their colleagues; however this often causes problems further down the line:<\/p>\n

\n
\"accident

such as ...accidents<\/p><\/div>\n<\/div>\n

Dont test with your team<\/h4>\n