{"id":5227,"date":"2018-01-09T04:10:40","date_gmt":"2018-01-09T12:10:40","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vsappcenter\/?p=2486"},"modified":"2019-02-16T15:30:34","modified_gmt":"2019-02-16T22:30:34","slug":"guest-post-your-guide-to-getting-feedback-fast-and-building-better-apps-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/appcenter\/guest-post-your-guide-to-getting-feedback-fast-and-building-better-apps-2\/","title":{"rendered":"Guest Blog | Your Guide to Getting Feedback Fast and Building Better Apps"},"content":{"rendered":"<p><em>This is a special guest post from <a href=\"https:\/\/twitter.com\/marcofolio\" rel=\"noopener\" target=\"_blank\"><em>Marco Kuiper<\/em><\/a>, Consultant at <a href=\"https:\/\/www.infosupport.com\/\" rel=\"noopener\" target=\"_blank\"><em>Info Support<\/em><\/a> and blogger at <a href=\"https:\/\/marcofolio.net\/\" rel=\"noopener\" target=\"_blank\"><em>Marcofolio.net<\/em><\/a>.<\/em>\n&nbsp;\nMany developers are good at <strong>building things right<\/strong>, but far fewer are skilled at <strong>building the right thing<\/strong>. While you need a strong idea of what problem you\u2019re solving for your users (and why and how), you can\u2019t rely on vision and gut feeling alone. Gathering insights and feedback from your users is critical to winning their loyalty, as well as to your long-term success and profitability as an app developer. <\/p>\n<p>In my work as a professional developer, I\u2019ve learned how to couple quantitative information with qualitative user feedback to ensure my team delivers the best possible user experience.  <\/p>\n<p>To help you do the same, I\u2019ll share: <\/p>\n<ul>\n<li>How to use <a href=\"https:\/\/appcenter.ms\/\" rel=\"noopener\" target=\"_blank\">Visual Studio App Center<\/a> to gather the necessary user and app behavior data required to make informed product decisions.<\/li>\n<li>A few of my favorite ways to collect less structured insights.<\/li>\n<li>Why both types of information are important and help you build better apps.<\/li>\n<li>Simple tips to apply what you learn from metrics and user feedback, and start improving <em>your<\/em> apps.<\/li>\n<\/ul>\n<p>At Info Support, we help organizations develop, manage, and iterate on web, mobile, and software solutions, as well as advise on strategy and the latest development techniques and best practices. Our clients range from\u202fthe\u202fagriculture and healthcare sectors to\u202fpublic mobility and financial services. <\/p>\n<p>I\u2019ll focus on B2B apps (defined as business to business, built for and distributed to employees via an enterprise store), since many of my projects target business users. While many of these principles apply to B2C apps (business to consumer, where apps are distributed publicly) too, there are also a few distinct nuances, namely how you distribute, market, and respond to user reviews.<\/p>\n<h2>The Importance of Getting Feedback Fast<\/h2>\n<p><a href=\"https:\/\/less.works\/\" rel=\"noopener\" target=\"_blank\">LeSS<\/a> uses a great piano analogy to reiterate the importance of getting feedback fast. If you\u2019re learning to play a piece on the piano, you hear a key\u2019s note immediately after hitting it. You get feedback immediately, and if something is wrong, you correct it. You learn fast, iterate, and keep improving. <\/p>\n<p>But, what if your piano didn&#8217;t play your note back until a week later? Learning to play the piece would take significantly longer, because you\u2019d be in the dark about any mistakes. When you delay feedback, it takes longer to learn what\u2019s working and what isn\u2019t.  <\/p>\n<p>The same is true for you as you build new features and functionality in your apps. <em>If you get feedback as fast as possible, you\u2019ll <strong>learn and adapt<\/strong> quickly<\/em>. The longer you wait, the more code you add, and it\u2019s significantly harder and more expensive to course-correct.<\/p>\n<h2>Beta User Groups and Feedback Collection in 6 Simple Steps<\/h2>\n<h3>Step 1: Set Up Your Beta Groups and Select Users<\/h3>\n<p>Feedback is important and beta users are your secret weapon to getting the insight you need. Listen carefully and be receptive to what they say, since they have a unique perspective that might be more accurate than your development team\u2019s; as hard as it is to hear this, it\u2019s usually true!   <\/p>\n<p><strong>One of my favorite tips: create a beta group of users who feel responsible and invested in the product\u2019s success<\/strong>, like team members who are your app\u2019s ultimate end users. Since their feedback will directly impact their future experience, they\u2019re likely to be more responsive and honest.  <\/p>\n<p>Bonus points: select a good cross-section of your total user population (not just across devices and locations, but characteristics like age and familiarity with mobile technology). From a size perspective, bigger isn\u2019t always better. We\u2019ve had great success with 30-100 active beta users providing feedback for apps with a user base of 10,000+.  <\/p>\n<p>How do you find beta users? Simple: <strong>ask<\/strong>. Send an open invitation to everyone at the company, asking if they\u2019d like early access and have an impact on your app\u2019s design and UX.  <\/p>\n<p>If you\u2019re a B2C app, it might seem hard to find the right beta testing profile, but the same general principles apply. Again, simply ask your users if they\u2019d like to get early access to new features and directly impact your roadmap. You\u2019ll be surprised at how many people are willing to help.<\/p>\n<p><img decoding=\"async\" src=\"\" alt=\"\" width=\"250\" class=\"aligncenter wp-image-2487\" \/><\/p>\n<p>Our definition of beta users (or testers) is <strong>a designated subset of your user population who receive early access to new features and directly communicate with the development team<\/strong>. Treat them like extended team members or friends, willing to spend time and energy providing feedback to help you make your apps better.<\/p>\n<p>Final tip: In communication, we call these users <strong>Ambassadors<\/strong>, not beta users or testers, to stress their importance to us and the role they play in our success. You could use another engaging, positive term, such as <em>Power Users<\/em> or <em>Head Starters<\/em>.<\/p>\n<h3>Step Two: Invite Testers into Early Development Conversations<\/h3>\n<p>My team uses Scrum, and we invite our beta members to join our Sprint Reviews for a few reasons: <\/p>\n<ul>\n<li>Showing beta users new functionality in real-time gives our development team the direct and immediate feedback we\u2019re after.  <\/li>\n<li>Sharing what we\u2019re planning in the upcoming iteration often leads to questions or reactions that steer what we build (or don\u2019t build) next.  <\/li>\n<li>Our beta users feel engaged, since they know we\u2019re making an effort to get their feedback throughout the development process, and we\u2019re truly listening.<\/li>\n<\/ul>\n<h3>Step Three: Get Test Builds to Users as Quickly as Possible<\/h3>\n<p>This one\u2019s easy. We suggest setting up App Center <a href=\"https:\/\/docs.microsoft.com\/en-us\/appcenter\/distribution\" rel=\"noopener\" target=\"_blank\">Distribution Groups<\/a> to automatically deploy app updates to your beta testers, notify them about new builds, and make sure they always have the latest version.  <\/p>\n<h3>Step Four: Establish Two-Way Communication<\/h3>\n<p>After you get your builds into users\u2019 hands, your testers need a place to share their thoughts, feedback, and problems.  <\/p>\n<p>We use <a href=\"https:\/\/www.yammer.com\/\" rel=\"noopener\" target=\"_blank\">Yammer<\/a> to interact directly; beta users post comments, upload files, @ mention relevant team members, and start threaded conversations at any time.  <\/p>\n<p>Invite your beta testers to an online communication platform, and, trust me, magic will happen: users provide feedback and communicate directly to the team (great!), <em>and<\/em> they\u2019ll interact with each other (better than great&mdash;magic!). Sharing ideas and \u201clistening\u201d to conversations between users is something we never expected, but it\u2019s led to making many of our projects hugely successful.  <\/p>\n<h3>Step Five: Be Responsive and Separate Signals from Noise (Prioritization!)<\/h3>\n<p>Be prepared for broad feedback and establish a plan for acting on user commentary, ranging from new ideas (we add these to the Product Owner\u2019s backlog), information that invalidates your assumptions or hypotheses, or compliments about your work (we love when we hear that we\u2019re improving users\u2019 workflows!).  <\/p>\n<p>Our Ops team plays a critical role in monitoring our Yammer networks, responding to questions, and helping users. When they a frequent request or identify an unsolved need, we discuss in our Sprint Reviews, prioritize, and add to our backlog.<\/p>\n<p><img decoding=\"async\" src=\"\" alt=\"\" width=\"1024\" height=\"573\" class=\"aligncenter size-large wp-image-2495\" \/><\/p>\n<h3>Step Six: Plan for Production User Feedback<\/h3>\n<p>Beta users are invaluable, but don\u2019t forget your end users. It&#8217;s important to make it easy for your production users to provide feedback, too. We invite users to provide app reviews via Zendesk, <a href=\"https:\/\/www.zendesk.com\/guide\/features\/community-software\/\" rel=\"noopener\" target=\"_blank\">creating a community<\/a> for each app \/ business, and inviting users to share comments or report bugs.  <\/p>\n<p>We have a dedicated support team to help users with questions and provide troubleshooting tips, so we don\u2019t always respond directly, but we monitor these conversations to see production users\u2019 feedback.  <\/p>\n<p>As an added, and unexpected, benefit, beta users often hop into discussions, responding to colleagues\u2019 questions, and offering proactive support when they see colleagues using our apps in the field. <\/p>\n<p><img decoding=\"async\" src=\"\" alt=\"\" width=\"1024\" height=\"555\" class=\"aligncenter size-large wp-image-2505\" \/><\/p>\n<h2>Beyond Beta: Use Feature Flags to Experiment and to Expedite Learning<\/h2>\n<p>Ready to supercharge what you learn from your users? Meet <strong>feature flags<\/strong>.  <\/p>\n<p>With <a href=\"https:\/\/martinfowler.com\/articles\/feature-toggles.html\" rel=\"noopener\" target=\"_blank\">feature flags<\/a>, <em>we deploy the same app to everyone, but enable\/disable certain features dynamically for specific groups of people<\/em>. Dynamically changing our app allows us to get feedback about specific features and helps us understand where we need to improve. Based on what we\u2019re trying to accomplish with the feature, we can compare users\u2019 reactions and gauge whether we roll it out to all users.  <\/p>\n<p>Building feature flags isn\u2019t difficult, and there are several implementation methods. We love statically typed feature flags (like <a href=\"https:\/\/github.com\/aspnetde\/simple-feature-toggles-sample\" rel=\"noopener\" target=\"_blank\">this one on GitHub<\/a>), because they allow us to easily test functionality with or without feature flags enabled.<\/p>\n<p>To implement feature flags in your apps:<\/p>\n<ul>\n<li>During app start up, retrieve flag state to see what functionality you can access and flag. This allows you to dynamically change how the app behaves after start up completes.  <\/li>\n<li>\nConfigure your backend to select a flag state based on a user identifier (such as e-mail address, employee number, user role, or geolocation).  <\/li>\n<li>\nDecide what functionality you\u2019d like to flag. The easiest option is to show \/ hide a certain UI element, while changing service call endpoints is more advanced.<\/li>\n<li>Configure your backend to release flagged features to certain users.<\/li>\n<\/ul>\n<p><img decoding=\"async\" src=\"\" alt=\"\" width=\"1024\" height=\"512\" class=\"aligncenter size-large wp-image-2515\" \/><\/p>\n<p>We use feature flags for both beta and production users, releasing different functionalities to subsets of users. For example, we may have one beta group, but we\u2019ll feature flag a feature for 10% of users.  <\/p>\n<p>App Center Distribution Groups simplify deploying specific builds (e.g. our test, feature flagged, or general availability versions) to specific user groups, and, to truly achieve Continuous Delivery, we <strong>separate the deployment and release process<\/strong>. <\/p>\n<ul>\n<li><strong>Deploying<\/strong> is both a technical and development team decision. Deploying is something that should have a certain cadence, like updating your app every two weeks (Continuous Delivery). <\/li>\n<li><strong>Releasing<\/strong> is a joint business decision. Your business stakeholders, Product Managers, and technical team decide when to ship new functionality to users. This doesn\u2019t have a certain cadence, but happens when your update is \u201cready or needed.\u201d<\/li>\n<\/ul>\n<p>Because we use feature flags, we build functionality and deploy, but hide from the user. When everyone decides it\u2019s time to release, we simply enable the feature for all users. <\/p>\n<p>Since we enable flags at start up, users see the new feature the next time they launch the app, with no updates required.<\/p>\n<p><img decoding=\"async\" src=\"\" alt=\"\" width=\"750\" height=\"704\" class=\"aligncenter size-full wp-image-2525\" \/><\/p>\n<h3>When to Feature Flag: Sample Scenarios<\/h3>\n<p><strong>Beta users<\/strong>: We fully test all new features, but releasing to production can be tense. Beta users to the rescue! We call a few testers, request they quickly check out a new feature, enable a feature flag, and distribute the updated version to their devices. Once they confirm it works, we\u2019re confident and roll it out.  <\/p>\n<p><strong>Production users and launches<\/strong>: Feature flags give us the flexibility to slowly push updates to all users, which is especially useful if you have a large user base, or want to verify that your backend can handle the additional traffic your new feature generates.  <\/p>\n<p>If you notice lag, or find a bug in your code, disabling a flag is quick and painless. Users don\u2019t need to install an update; the \u201cflagged\u201d feature is just disabled in their existing app.  <\/p>\n<h3>Feature Flagging Best Practices<\/h3>\n<p>When you\u2019re getting started, it\u2019s hard to know what to flag and when, but a few things to remember:<\/p>\n<ul>\n<li>Your code must be robust and well tested. Feature flags add complexity, so unit and UI tests become even more important.  <\/li>\n<li>Your feature flags shouldn\u2019t conflict. If your flags conflict, you run the risk of confusing your users, degrading the user experience, and introducing bugs. Feature flagging several features is tempting, but also makes it more difficult to determine if you\u2019re seeing real results, or the result of users bumping into conflicts or issues with your code.<\/li>\n<li>Note that feature flagging and separating deployment from release requires all users to have the latest version of your app installed (or the version where you\u2019ve included the feature flag you\u2019d like to roll out). Users with older versions won\u2019t see the new functionality, even if you enable the feature for all users.  <\/li>\n<\/ul>\n<p>If you\u2019re a React Native developer, App Center\u2019s <a href=\"https:\/\/microsoft.github.io\/code-push\/\" rel=\"noopener\" target=\"_blank\">CodePush<\/a> service allows you to use feature flags to A\/B test and experiment with different implementations. You create two (or more versions), push updates to users instantly, log anonymous responses and user engagement, and can return to \u201cnormal\u201d at any time. <a href=\"https:\/\/blogs.msdn.microsoft.com\/vsappcenter\/ab-test-all-the-things-react-native-experiments-with-app-center\" rel=\"noopener\" target=\"_blank\">Check out John Wargo\u2019s blog post to get started<\/a>. <\/p>\n<h2>Numbers and Metrics Matter, Too<\/h2>\n<p>Now that we think we\u2019re heading in the right direction, we need numbers to back up our beta feedback and feature flag results.  <\/p>\n<p>Using <a href=\"https:\/\/docs.microsoft.com\/en-us\/appcenter\/analytics\/\" rel=\"noopener\" target=\"_blank\">Analytics<\/a>, especially <a href=\"https:\/\/docs.microsoft.com\/en-us\/appcenter\/analytics\/event-metrics\" rel=\"noopener\" target=\"_blank\">Event Metrics<\/a>, we\u2019re able to learn more about the behavior of our app and our users (as well as user demographics). Are people actually using the new functionality? If so, how? Did the change we pushed affect user engagement or time spent in app? <\/p>\n<p>Several factors shape our decisions to move functionality to production. Beyond the obvious, \u201cit works as expected,\u201d feature flags help us compare and contrast how new features affect user experience.  <\/p>\n<p>To do this, we: <\/p>\n<ul>\n<li>Give any new feature a unique name, so it\u2019s easier to find and analyze logged data. <\/li>\n<li>Use <a href=\"https:\/\/azure.microsoft.com\/en-us\/services\/application-insights\/\" rel=\"noopener\" target=\"_blank\">Application Insights<\/a> to drill into usage (time in app, sessions, etc.).<\/li>\n<li>Extrapolate beta tester (or feature flagged group) data to see how the feature will affect all production users. <\/li>\n<li>Measure against our goals. For most B2B apps, we aim to make users more efficient, increasing worker productivity, and helping them get back to work faster. If a new feature causes users to spend less time in our apps, we\u2019re on the right track.<\/li>\n<\/ul>\n<p>Ultimately, the product owner makes the final decision on what we do next. He or she answers the hard questions: should we continue our efforts or take a different route? But, with both quantitative and qualitative information at their disposal, our product owners are confident that they\u2019re guiding the team in the right direction. <\/p>\n<h2>Final Thoughts<\/h2>\n<p>To <strong>build the right thing<\/strong>, take both your beta and production user feedback seriously, and back up it up with data from a service like <a href=\"https:\/\/docs.microsoft.com\/en-us\/appcenter\/analytics\/\" rel=\"noopener\" target=\"_blank\">App Center\u2019s Analytics<\/a>.<\/p>\n<p>Balancing your apps\u2019 metrics, engagement stats, and user feedback is never an easy task (check out <a href=\"https:\/\/blog.yesinsights.com\/qualitative-vs-quantitative-feedback-one-better\" rel=\"noopener\" target=\"_blank\">one of my favorite blogs on the topic<\/a>). The more you know, the easier it\u2019ll be to make decisions.  <\/p>\n<p>With numbers and opinions, you\u2019re more likely to discover that something you think is a major issue doesn\u2019t impact your users, or&mdash;more likely&mdash;the reverse. Your reports might not pick up something that\u2019s a frequent point of contention in user forums or with your beta testers.   <\/p>\n<p>Once you nail the quantitative-qualitative combination, you\u2019re on your way to working on apps that are fun to build <em>and<\/em> that beloved by your users.\n&nbsp;\n&nbsp;\n<em>If you haven\u2019t already, <a target=\"_blank\" href=\"https:\/\/www.visualstudio.com\/app-center\/\" rel=\"noopener\"><em>create your Visual Studio App Center account<\/em><\/a>, connect your first app, and start shipping better apps now.<\/p>\n<p>Have an account? <a target=\"_blank\" href=\"https:\/\/www.visualstudio.com\/app-center\/\" rel=\"noopener\"><em>Log in<\/em><\/a> and let us know what you\u2019re working on!<\/p>\n<p><strong>About the Author<\/strong><\/p>\n<p><a href=\"https:\/\/twitter.com\/marcofolio\" rel=\"noopener\" target=\"_blank\"><em>Marco Kuiper<\/em><\/a> is a Consultant at <a href=\"https:\/\/www.infosupport.com\/\" rel=\"noopener\" target=\"_blank\"><em>Info Support<\/em><\/a>, blogging on <a href=\"https:\/\/marcofolio.net\/\" rel=\"noopener\" target=\"_blank\"><em>Marcofolio.net<\/em><\/a>, frequent speaker and is always incurably optimistic. He inspires and motivates people to share and expand their development knowledge.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>This is a special guest post from Marco Kuiper, Consultant at Info Support and blogger at Marcofolio.net. &nbsp; Many developers are good at building things right, but far fewer are skilled at building the right thing. While you need a strong idea of what problem you\u2019re solving for your users (and why and how), you [&hellip;]<\/p>\n","protected":false},"author":42,"featured_media":38034,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[16],"tags":[4,5,8,10],"class_list":["post-5227","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mobiledev","tag-analytics","tag-cicd","tag-distribution","tag-guest-post"],"acf":[],"blog_post_summary":"<p>This is a special guest post from Marco Kuiper, Consultant at Info Support and blogger at Marcofolio.net. &nbsp; Many developers are good at building things right, but far fewer are skilled at building the right thing. While you need a strong idea of what problem you\u2019re solving for your users (and why and how), you [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/posts\/5227","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/users\/42"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/comments?post=5227"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/posts\/5227\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/media\/38034"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/media?parent=5227"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/categories?post=5227"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/tags?post=5227"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}