The Friday the 13th event was the second meeting hosted by Nathan Bussiere and Alex Soufi at Bancvue, and, while we were trying to figure out what to do before, this time we had a game plan and adopted a Lean Coffee Kanban format and picked topics for the group to discuss. We really only had time for two. The first was: What KPIs should I be tracking? How often? How do I relate them to business value(s)? The gentleman posing the questions said that he had used NPS (Net Promoter Score) and SUS (system usability scale) and wondered what else there was in the wild. Jeff Neria suggested that the key performance indicators to track might vary based upon one's business model. In a subscription based model you might measure churn (eventual drop off) and if you are just selling one off products online you might measure a different kind of drop off rate, persons losing interest or getting frustrated/disenchanted on their way through the workflow which should close a sale ideally. It may be hard to relate churn back to any one thing that you did if you are releasing every six months. Jeff suggested it smart to figure out what one metric you really want to track, (what is the one thing you really want to change and improve?) and then try to figure out how other metrics tie into the bigger metric. If reducing the number of clicks to do things in an app ultimately boosts an end goal metric like sales conversions, then as much might be an example of a supporting metric. If not, then it’s a distraction. The man who asked the original questions suggested that surveys were helpful while seeming to want to find another solution as if suspecting that they were not the answer to everything. Alex spoke of a desire to optimize the screen and make the process easier for users trying to get from here to there. He offered an example of an interface that forced a user to complete two dropdowns for country and language. This interface was simplified to only have one dropdown for country. How many clicks does it take to complete a task? Is clickiness a problem? Actual system performance and perceived system performance are two separate metrics worth worrying about. Alex also spoke of trying to minimize the JavaScript in interactive design in the name of these concerns and furthermore suggested that one shouldn't try to collect name/phone/email from users at forms if one is never going to contact that person or do anything with the information. A concept from a different talk I once saw Tim Ash give on optimizing forms for conversion: Keep forms that users must fight through simple so that the fight is as little of a fight as possible in the name of minimizing frustration and thus drop off. Only ask them about the information you really need and don't have a bunch of noise on the screen causing other distractions or making it unobvious as to what to do. Alex suggested that "fail, fail fast, and fail often" was a great mantra. Be ready to abandon ship. In the real world there is often not time and budget to undertake what is right and do surveys and gauge markets so a creative team just ends up throwing something together and in these situations in particular they need to course correct quickly. Having shorter sprints will help with this. The second topic of discussion was "How do I engage developers more in collaboration?" and Jeff Smith, one of the original board members of Agile Austin, suggested that holding lunches where there would be free food was a good idea. The woman posing this question said she just heard crickets when trying to get developers interested. This in particular seemed to be a problem on teams that had just switched to Agile where there is a newness factor. One of the developers in the room flatly asked "What's in it for me?" in retort. Alex suggested that developers often feel the pain of trying to implement a design handed down to them only to realize that it was not implementable and that these painful memories would serve as good incentive to give feedback to developers. Jeff felt that developers aren't so much coldly indifferent to UX as they just have more than they can do in a day at any one day. Dev leads are all the better to try to coax into a meeting because the underlings of the dev leads will follow their leaders into such meeting, but these individuals, dev leads, are all the more likely to be spread thin with other meetings. If you don't want to be involved in the UX process as a developer then there is something really wrong, but Jeff felt that inattention often stemmed not from apathy or irritation but from overextension. Alex suggested that there are two types of developers, the ones to whom you just give stuff and they just do and the ones who come back and fight you. Alex reiterated a need to set a rule wherein individuals had a certain window of time to complain and would lose their abilities to challenge afterwards. This should incentivize developers to be involved. Jeff suggested doing creating exercises on Fridays to get others involved. He often draws with a team lead and a QA lead. He felt the garbage in, beauty out UX principle applies to everyone and that developers who think that they don't have a "design sense" just need to be encouraged to blossom. He said that: "It's a myth that there is a creative department." Everyone can be creative.
No comments:
Post a Comment