You are responsible for your product and how it's used, not the users.
One of the best things about being a developer is that you can create. In order to bring your ideas to life, you ramble on some keys and watch how they turn into screens, functionality, business rules, and hopefully; pure value.

In my 16+ years as a developer, I've listened to a lot of developers, makers, and entrepreneurs that complained that their app was being misused, how the user doesn't get it, or how users are causing all kinds of bugs. But to be honest, we as makers need to take responsibility for what we make.

This article will show you 5 ways to take control of the product creation process so you don't have to blame the users for doing things wrong. It's time to stop pointing fingers, and take responsibility.

TL;DR

With creation comes responsibility. Take responsibility and don't blame your users for crashing your solution or showing you its bugs.

A Magical Analogy

Imagine there is this magical place, a magical forest if you will. It is packed with beautiful things like rainbows, unicorns, and stuff.
But as with any place, unpleasant things lurk there as well. Poison plants that can make you sick for days, and little flesh-eating beings that smell fear and can throw themselves at you.

You are called The Wise One by people near the forest since they know you created the magical forest many centuries ago, and know everything about the magical forest and the creatures and plants that reside there.

People come to you for when they need something to help their sick kid to get well and know that you can get the medicine from the magical forest.
When someone went to the forest and got attacked by a vile creature you are the first one that will be notified by the small unichipmunks that live in the trees about such an event.

Now replace "magical forest" with your application and magical things with useful features.

Can you guess what the evil things are?

Yup, it's those bugs that crawled in your product. And inconsistencies in your interface. And those assumptions about users, their needs and behavior that you neglected while building your product...

You are Responsible; Act Accordingly

Yes Ma'am / Sir, YOU, the creator, are fully responsible.
When you create something and people have accepted your creation in their lives, you become responsible for what you've created.

This counts even more so for applications that you are charging hard-earned money for.

When people purchase something from you, its because they expect value from it (or they just wanna donate to you, mostly value is the reason). They also expect that you, the creator, provide value to them by giving support.

One of the most frequent sounds that you'll hear from people who built a product is that support becomes a huge part of their time spending after they launched a product that starts getting traction.

Some of the most common reasons why people need support (based on personal experience on implemented solutions):

• Users don't understand the functionality and/or interface
• The app contains bugs that prevent users from using it properly
• The app doesn't take into account actual user behavior (IX) and throws off users that are using your app

When you've put a lot of work into a product, you hopefully are proud of what you've created. And it sucks when people are negative about it.

Even worse, if you know that your product works but your user refuses to operate it as designed and wants to do things differently, that can be a frustrating moment. But it DOES mean that your product is off somehow.

So don't take grudge out on your users. They are the valuable input source that resonates with whatever product you've built. And their input and feedback is the pure gold in product development country

How To Take Control?

Let's find out about five ways that will help you to get in control of how your app is anticipated and used by your (future) users.

1. Talk With People 🗣

The uttermost efficiënt way to get in control of your users and minimize the delta between assumptions, expectations, and reality is...

Talk. With. Your. Potential. Users.

Not to. But with them. Converse. Engage and discuss.
It's that simple. It isn't easy, but it IS simple. You need to get out and gain insights from talking to users.

First off, talk about people's struggles and daily issues. Check if their pain points are related to the solution that you have in mind.
And find out how they are coping with those issues now and here, where your solution isn't around (yet). The sooner you get feedback without biassing your users, the cheaper it will be to change things and finetune your solution's angle

2. Verify Your Idea 🐒

After you've been interviewing and researching the problem, you probably have a heads-over idea of how the solution is going to operate.

After you've been interviewing and researching the problem, you probably have a heads-over idea of how the solution is going to operate. In order to take responsibility, you need to find out if your solution is the right solution for your users.

At this time, where you've probably put together your idea - whether it be as wireframes, sketches on paper or an interactive Mockup - you can take your solution for a test drive. No code involved yet, so testing this and noting what people think is missing, weird or not clear is useful as heck for your solution. This will help you to understand if your solution fits the need of your (potential) users.

If you can somehow record, register or at least note what was tested and how it was done, you are letting users perform monkey testing for you. By writing down how things are reproducible, you can fix these issues by creating a new version with updates or added (or removed) functionality.

Key to make this a success is to instruct people that are going to test your product that they need to keep in mind what they did and give them a construct on how to register their findings.

Not surprisingly, automated (AI) monkeys are emerging as online services as well. See Monkeytest.it if you'd like to run a free monkey test.

3. Cover Common Usability Issues ✅

Once you've established a nice functional prototype (you're not done, but using the 80/20 rule, you've got a stable version) you are probably going to start creating your MVP or a prototype of your application.

When you do so, the last thing to take into account is the most common user interactions that lead to issues and problems. This comes down to implementing best practice stuff like:

• input checks
• self-explanatory screen setups
• guidance user-interface elements
• consistency between labels, buttons, etc.

I won't be listing the best practices here as the internet is bloated with useful content regarding them. Just Google for "common usability issues" and you'll get a nice list.

Just stop getting mad at users because they're clicking that button two (or ten) times in a few nanoseconds. It's human nature to do things like that. Stop freaking out about it!

4. Test Your Solution 🕵🏻‍♂️

Test Driven Development (TDD in short) and Business Driven Development (BDD) are techniques that have increasingly become popular in the last decade.

By defining tests that orchestrate how your app should work (TDD), or by even writing down business rules and defining the tests beneath them that enable those rules (BDD), you can make sure that your app's code functions properly.

When you're working on fixing bugs, building in some of the user's feature requests that you decided to be of value for your product, you can be in control by writing tests that will focus on those things.

ie: Someone reports an issue and the origin seems to lie in the fact that the user is able to get past a validation that is necessary for your app to function correctly.

You fix this by:

• writing the appropriate test(s)
• changing the code to make all tests go green and fix the issue
• you deploy to production

Test Strategy
In its simplest form, defining a valuable test strategy isn't really that hard. But you need to do it the right way, else it is just a farce that implies you're imnproving quality while it doesn't cut it.

I've been a systems test coordinator for a Dutch bank besides being a developer in their IT department.
There, I learned the ropes on setting up test strategies, and there are two things that define 90% of it:

• the highest risk areas need the most/best testing effort
• the aspects of the subject under test that matter most help defining how testing is setup

Risk Analyses

This is all based on the following formula:

Risk = Likelihood x Impact

ie: Twitter-based sign-in functionality on your login page might not be used all that often. So the estimation for the likelihood could be low or medium. But if it doesn't work chances are that people are leaving your app and start ranting on Twitter about it. Thus this would make the impact have a value high.

According to our estimation, the Twitter sign-in functionality would be placed in the top center area of the matrix, making it a high priority.

If you do this for all the aspects like functional parts, business rules, etc. you get a nice overview of where your priorities should be at.

Quality Attributes

There are lists of quality attributes available online (like this one on Wikipedia) that can help you decide what aspects are most important for your product.

ie: Your online blogging platform might be valuing security, maintainability, localizability, and durability as the most important aspects. If so, you can work on setting up tests that make sure that those aspects are working correctly. Think of security testing sets, unit tests for everything that's medium priority or above on the risk matrix to support maintainability. Or tests like load tests to test if your solution is durable when 10000 users will use it in a single hour.

Discussing testing on its own goes beyond the scope of this article, but you can find out more about these things by Googling.
With the two concepts of risk analyses and quality attributes you at least know about some basic concepts that can help you take control of both your app's functioning and quality.

5. Make Giving Feedback Easy 🤗

In order to prevent people from raving around the internet about how awful your app is, you need to be open for feedback.

You need to open up both in a personal and a technical sense.

Personally Accepting Feedback

Accept that people will always have remarks, misunderstandings, issues, and bugs. And thank them for wanting to ventilate those to you.

Ignore the input that is vile and disturbing or downright a-social and focus on real user feedback and constructive responses.

If you have a mindset that appreciates feedback people can truly open up you will be amazed at what you can learn from it.

Technically Making Feedback easy

Where it used to be all email-based feedback, the internet nowadays provides some awesome technical ways for lowering the barrier between product makers and product users.

Chat functionality
The quickest technical way to open up for users is to integrate chat functionality like Tawk.to, PureChat, etc. They provide widgets that you can add to your site and that lets users leave a message or interact with you when you are online. Realtime chatting can be a true win-win situation if you can afford to take some time for short interaction cycles with the users of your product.

If you want a more formal way of interacting you could use service desk enabling solutions that let people send in issues on their own.

Service desk tools
Bigger businesses might use service desk tooling and issue tracking software to register issues and bugs. Think Jira, Zoho Desk, just to name a few. Or get an open-source variant for free like Bugzilla.

Feature request & voting
By letting your users register feature requests and lobbying for them amongst your users, you can have a community-orchestrated feedback mechanism that can show you what features are considered most important.
By enabling services like Microsoft's Uservoice or a free (custom hostable) open-source variant Fider, you can let your users add feature requests on which other people can vote and respond.
I've seen some amazing feedback by users to parties like Microsoft. It also prevents that you have to answer the same requests over and over again, thus lowering the effort needed from your side.

There you have it. Three technical ways of opening up to your users and embracing their feedback.

Please note that simpler solutions like chatting might be interesting from the get-go, whereas more formal interaction like bug reporting and feature requests are probably more suitable when your user base is going past the tens of users range.

Embrace your user's feedback. It will make you smarter, more humble, and help you to aim for the right problem at the right angle

To Conclude

In this article, I've shown you several ways and moments of the product development cycle where you can take control of any abuse, misusage, misunderstanding or plain pestering that you might experience from what appears a user taking down your beautiful product.

The five ways to take responsibility for your product as mentioned in this article are:

• By talking with (potential) users early on, you can check if your idea will form a proper solution to a problem / a need to a want

• By monkey testing your sketches, wireframes or mockup you can find out about the biggest roadblocks and learn from the people that are checking out your solution early on

• A lot of common problems have been thoroughly documented online. Check out about the most common user interaction issues and make sure you have your answer to those implemented in your solution. This is a quick win that will save you a lot of worries when you consider them while building your prototype or MVP version

• When you have a usable version available, enabling interaction and providing guided means for users to send feedback to you is golden. This will often prevent them from ranting online and will give you a heads-up about issues. By using feature request solutions you can even let your users give you insights on their wants and needs

• Using a testing strategy, you will be able to see where you need to put in your efforts regarding quality assurance and testing user scenarios. Basing it on risk analyses and the most important quality aspects of your solution

There you have it.

There's no point in pointing your finger 👉🏻 towards your users when something breaks just because they aren't using it as you intended it to be operated.

As a maker, *YOU ARE RESPONSIBLE * for the success of your product and the value that it provides. Users will always manage to break stuff or use it in ways you could never have imagined​ before.

So take control, and take advantage of the tips and pointers so you can embrace the user and what they got to offer.

Building value for the user is best done when coöperating with your users.

Take care and keep building #valuefirst solutions.

This article was originally posted on Shipharder.com

Disclaimer: I am not affiliated with the products mentioned in this article in any way.