Roadmap Suggestions: Improving a SAAS like InLinks

Would you like to inspire or help direct our product roadmap? We would love to hear your ideas – whether they are minor UX bugs or significant projects, we need to get on with to make InLinks the best tool it can be.

Your Customer Journey is Our Journey

InLinks is a small team and in fact we are very lucky to have a tool which helps us plan our content in a systematic manner. However, we are only as good as our customers. So to make us look good, we need to make you look good first! That’s a constructive way to look at product development. We are all ears if you can help keep us on the straight and narrow.

There are several ways in which you might affect what we develop next.

How to suggest Fixing UX Bugs

Obviously, if something is not working, then we need to fix that – especially if it is something that is annoying lots of users. However, a more subtle problem is how we should improve our UX. UX is surprisingly complex, without User feedback. As we develop a tool, we may be blind to seeing a page the way the user does. In the summer of 2022, we hired a UX Professional just to help us with our home page – let alone all the pages after login. This in the end resulted in a complete revamp of the site’s architecture! What seemed like a small problem of messaging turned into several months of effort. Ultimately, we even took the opportunity to update our domain name. On the plus side, the main site BEFORE logging in is now based on WordPress. That makes much of the non-logged-in content and layout easy to modify.

Anything you see with the .com domain in the URL is WordPress driven.

The core of the tool, though, remains on the .net domain. This is custom-coded. It’s where the magic happens, and most of it is not something we want to share with the search engines! This is the meat of InLinks.

Please be Specific UX recommendations

If you think the layout of something is wrong – or you cannot quickly get to what you need, when you need it, be SPECIFIC about what we should do to fix it. Developers are not mind readers. They initially program to provide function, then try to make it work for the user. It is easy to have blind spots in this process. One way to do this is to use Powerpoint to show a screenshot, with a mock-up or how you would suggest it is improved.

The more specific a UX suggestion is, the less work is involved in understanding and fixing it. That means there is a direct correlation between the clarity of your suggestion and the speed with which it can get integrated into the product.

Provide Screenshots for Bugs

A picture does say a thousand words when it comes to fixing bugs. Trying to describe a bug in words is hard. Trying to understand what your mean is even more complicated. When providing a screenshot, please try to include the whole screen – or at least a screenshot that contains the URL that you are using. That way, the developer can try and recreate the issue. From there, it is much easier to spot the code that needs changing on our side.

Recommending Large-Scale Changes

We have ideas on how we want InLinks to develop as a SAAS. Unfortunately, we will never have time to implement everything we want. We are a bootstrapped business, and whilst we could take the money from the VCs, to speed up development times, we are still moving fast with our small, nimble team. Scaling too quickly comes with multiple challenges. So if you believe that we should suddenly create our search engine (or some other massive endeavour), you might be pushing your luck! 🙂

More significant projects will need more detail than a simple bug fix or UX suggestion. A large part of the detail has to be about the “why”. Unfortunately, this is where our agenda and yours may diverge. For example, if I were a user and wanted to downgrade a SAAS, I would RATHER press a button than have to message a human. But this would require lots of programming at our end for zero gain. Here is an example. We have some people asking to downgrade, but they still have too many pages in the system to be able to downgrade. It is easier in these cases to go straight to human interaction, to resolve the problem.