Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Seek & Destroy: How Breaking Builds Stronger Products

    - Keegan Dillman

  • Nothing personal

    This one's tough. It can be hard to take criticism on thing you work on and create, people are attacking what you and your team have poured hours into and they are saying it wasn't worth it, right? Not exactly. Feedback can be hard to take, but people testing your product aren't just out to hurt feelings, they want to help create something even better.

    In particular, communication through emails, instant messaging and ticketing systems can seem misleadingly cruel by way of unemotional text. Reading feedback in just plain text can seem more hurtful than its intention; a text document can't mimic the subtle tone changes, gestures, inflections and other in-person communicative methods which can "soften" what's being said.

    No matter how nice the feedback is phrased it can be a hard pill to swallow when it comes to changing something you were in charge of creating and that's fine, going through that is just a step in the process that gets easier through repetition. Occasionally you can get lucky after revisions to have things set back the way they were, but rolling with the punches can yield a better product and process in the end.

    Of babies and bathwater

    Being able to cut the apron strings on features within a product is hard, harder still if you made that feature or spent a lot of time with it. Being able to trim the unneeded or non-essential parts of a product can save a team a ton of time and open them up to regroup on other important work and issues.

    Maybe you're proud that the app can be accessed via a touch-gesture on mobile, but that same process is error-prone or your end user doesn't use it: it may be better to remove that feature (with its bugs) and focus on another task that is needed. This applies not only to implemented functionality but how that functionality is implemented, the functions and calls made to the server could end up causing a lot of slowdown for the product and may have to be reworked to allow a faster user experience.

    The take-away

    All of this is in pursuit of one thing: the better product. It's why you went and started work to create it, after all. Any testing or user feedback isn't done out of malice, just the want for a better experience and product. Remember: let breaks create a better experience, don't take the feedback to heart, take the product from the potentially overprotective arms of their creator and know when to let go of problem areas.

    Prep your product, and get ready to seek and destroy.


comments powered by Disqus