Start up business challenges of ISVs - How to build a user friendly product
Start up business challenges of ISVs - How to build a user friendly product
This time we will talk more about the startup challenge how to build a user friendly product.
This time we will talk more about the startup challenge how to build a user friendly product. As we are guiding a lot of ISVs in their technical journey, we do see a lot of products, applications and solutions being build. I believe it would be interesting to share some best practices and experiences.
A user friendly product leads towards a better experience, satisfaction and will support the overall relationship between the software vendor and customer. In my article earlier I described 4 main topics, I will focus in this article on 2 topics only, as we already covered the other topics in different articles.
When I was doing my studies and research into these topics, I found a must read if you feel interested by Reliability.
Let’s go with Reliability and Interface!
The first part of an user friendly product goes with a reliable product. A reliable productshould provide a consistent and predictable experience when being used. It should do what it has been made for and it should do this every time you are using it. If you are using a fan during the summer, it should blow some air in the space and it should “refresh” the air. Depending on the level of power, it will be soft or hard blowing. This will make it trustworthy in an human context. A digital product is a bit more complex, i.e. if the product is in production phase you need to keep in mind the performance, other products and services that rely on this will not be affected. Besides, the infrastructure, code, configuration, deployment and runtime environments can be flexible too.
Reliability expectations are based on a resilient fundamental. Can the product be used to adapt to other workloads? And, what happens if the product will “break” from its original purpose, can it be fixed? Resilience is the ability to absorb and adapt to, as well as recover from, a disruptive event. A resilient product is expected to be able to resist to an extreme event with minimal damages and functionality disruptions during the event; after the event, it should be able to rapidly recovery its functionality similar to or even better than the pre-event level.
The reliability of a complex object, like a software product (which needs constantly to adapt its environment), is dependent on how resilient you engineer it to be. When building a reliable product we will need resilience engineering.
Continuous development of technology, such as Cloud Computing, means you are using a base-level for resiliency. With the newest business models such as Serverless you will have a more flexible and agile model where resiliency of your solutions can be narrowed to focus on your actual code and how well you can configure the cloud platforms they utilize.
As we a centralizing our customers in every article, this time the customers view is important to meet the expectations on reliability. It is important the software engineering team understand the customer success KPIs. Building up Service Level Objectives can support you building the product on the customers’ expectations. Ask your customers about their expectations and evaluate this internally when developing a product.
Then the question remain, how to measure reliability. We have 2 types of indicators, leading and lagging indicators. Gathering metrics such as incident rates, customer service calls and reporting on the decline or increase is a poor way to measure reliability, because it gives no indication of how your products may respond to future or unforeseen events, these are indicators because they are only obtained after an event occurs.
Leading indicators are factors that predict a certain outcome, towards a future event. This gives you the opportunity to act and anticipate before the event actually happens. However, this are indicators and are not always correct. The ideally measurement would be a mix of leading with lagging indicators to create a reliable product. You can use metrics like Lead Time, Mean Time To Restore and Change Fail Percentages.
The second part of a user friendly product relies with the interface. A good product interface makes it easy for users to use the product and after receives back understandable information. An interface comes with many side effects, such as: interaction, graphic design, lay-out, symbols, technical interactions, etc..
I will guide you with some practices for a good interface, starting with be clear. A clear interface helps prevent user errors, makes important information obvious and contributes to ease of learning and use. Clear interfaces should explain by itself what it does and what outcome you can expect, i.e. the search symbol to search within a product. Clear goes hand in hand with simple. The best interface designs are simple. Simple designs are easy to learn and to use and give the interface a consistent look. A good design requires a good balance between maximizing functionality and maintaining simplicity through progressive disclosure of information. i.e. the iPhone 8 was made with only 1 push button in the front screen. From any application it guided you back to its home screen. Important to mention is the users must see the visible cause-and-effect relationship between the actions they take and the objects in the product. This allows users to feel that they are in charge. And keep in mind every visual element that appears on the screen potentially competes for the user's attention. Provide an environment that is pleasant to work in and contributes to the user's understanding of the information presented.
This sounds pretty straight forward, now let’s get the users involved to get this great experience. Today’s experience demands products should be able to reflect the characteristics of their users’ thoughts and behaviors. Therefor it would be recommended to understand and research your target audience and users. Besides, conform your product to the experience and designs of some other products that have achieved success and been commonly accepted.
You will need your users in several steps: before designing, evaluation of the design, when prototyping, when releasing and when evaluating.
Start with identifying who are your users and how they are going to use it. At this point, you should explore:
User’s needs, challenges, and problems;
User types, their experience, level of knowledge and skills;
What activities they can do using your system.
When building your products you can’t skip this step. We discussed in article #2 the value proposition and it would be a strong approach to engage with the same users to get their feedback on the interface. If you have multiple value propositions or your buyer is a different persona then the user, please focus on users only here.
When developing your product keep your users close and gather feedback all the time. You should create a prioritization based on all the feedback. You should focus on optimizing the direct impact and make your product more user friendly and create a roadmap for any additional features and feedback to make your more comprehensive. The better you involve your users in your development, the more ambassadors you will have and more customer satisfaction you will have.
Bottom line, you need to build a reliable product by gathering customer feedback. Do this proactively when developing products and releasing them, but also when failing occurs. Define the right lagging and leading indicators to meet the customer expectations. When it comes to interface you need to understand and involve your users. Start a research before designing and ask for feedback in every step you are making. Try to keep your interface clear, simple and consistent.
Interested to learn more?
If you feel interested to learn more about how to create a user friendly product when it comes to Reliability and Interface, please reach out to us to discuss the opportunities. Please find our contact details here.
Global ISV Lead and business developer at Intercept