Comments on: Observations versus Recommendations https://www.90percentofeverything.com/2011/03/29/observations-versus-recommendations/ User Experience Design, Research & Good Old Fashioned Usability Wed, 01 May 2019 06:04:43 +0000 hourly 1 By: FOG: Difference between Opinion and Guess? https://www.90percentofeverything.com/2011/03/29/observations-versus-recommendations/#comment-516501 Fri, 11 Oct 2013 15:22:29 +0000 http://www.90percentofeverything.com/?p=5181#comment-516501 Very interesting. Still, what is the difference between an opinion and a guess. They seem to me so close..

]]>
By: whaiouhwoaihwoiaw https://www.90percentofeverything.com/2011/03/29/observations-versus-recommendations/#comment-409907 Wed, 20 Mar 2013 11:17:34 +0000 http://www.90percentofeverything.com/?p=5181#comment-409907 ve noticed a fair few designers muddle up observations with recommendations when analysing user research findings. This can really screw up your design process, but thankfully it’s quite an easy one to avoid. It’s important to always state observations separately from your design recommendations, and to try to state them in a pair. Observations are facts like “Participant 3 failed to create an account successfully” or “There’s a 25% drop out rate on step 3 of the wizard”. If you start with these facts, you add structure to the discussion: all the stakeholders can do at this point is acknowledge that there is a problem, or discuss the validity and generalisability of the observation. Once you’ve cleared this hurdle, then you can move onto the fun bit: design recommendations. One common mistake is to make a blanket statement about user research, followed by a design recommendation e.g. “User research indicated that there were problems with this area, so we should change all the labels as follows…”. This is bad because it’s opaque. What user research? What problems exactly? Without establishing a bedrock of fact, your recommendations cannot be evaluated properly and could lead you into a bad place. Another common mistake is to suggest the research findings specifically require a certain design change, e.g. “In the usability test 6/8 users failed to notice error feedback in the payment form, so we absolutely must to use red text here”. User research rarely, if ever, necessitates a specific design change – and until you make that change and test the impact, you cannot know how effective it will be. There will always be myriads of design alternatives, and everyone will have their own opinion. Heated discussion may occur at this point, but that’s OK – the solution is to design and test the advocated approaches.]]> I’ve noticed a fair few designers muddle up observations with recommendations when analysing user research findings. This can really screw up your design process, but thankfully it’s quite an easy one to avoid.

It’s important to always state observations separately from your design recommendations, and to try to state them in a pair. Observations are facts like “Participant 3 failed to create an account successfully” or “There’s a 25% drop out rate on step 3 of the wizard”. If you start with these facts, you add structure to the discussion: all the stakeholders can do at this point is acknowledge that there is a problem, or discuss the validity and generalisability of the observation. Once you’ve cleared this hurdle, then you can move onto the fun bit: design recommendations.

One common mistake is to make a blanket statement about user research, followed by a design recommendation e.g. “User research indicated that there were problems with this area, so we should change all the labels as follows…”. This is bad because it’s opaque. What user research? What problems exactly? Without establishing a bedrock of fact, your recommendations cannot be evaluated properly and could lead you into a bad place.

Another common mistake is to suggest the research findings specifically require a certain design change, e.g. “In the usability test 6/8 users failed to notice error feedback in the payment form, so we absolutely must to use red text here”. User research rarely, if ever, necessitates a specific design change – and until you make that change and test the impact, you cannot know how effective it will be. There will always be myriads of design alternatives, and everyone will have their own opinion. Heated discussion may occur at this point, but that’s OK – the solution is to design and test the advocated approaches.

]]>