A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
Today a customer sent me a support email stating that my software is crap, that if I had designed the GUI like a particular competitor that I will sell more copies.
He is not alone, I noticed that many of my customers are using the competitors product and are familiar with their GUI before switching to mine.
I'm somehow confused. I want to help and support my customers but I also will never clone a competitor.
Have you experienced something similar from your users? Please share your thoughts.
You need to develop a bit of a thick skin if you are doing support (particularly B2C). He's entitled to his opinion. But I wouldn't lose any sleep over it. Look on the bright side - at least he cared enough to email you!
I certainly wouldn't advocate wholesale copy of a competitor. But maybe there is some superior element or idea in their UI that you could incorporate? Perhaps you could ask your critic to be more specific?
Wednesday, August 28, 2013
You don't have to "clone" the competitor's software, but maybe study it to see if it streamlines certain common functions in a way that you can learn from.
Wednesday, August 28, 2013
You've totally missed the point.
When your potential customer sends you an email like this, it is gold, especially if they're willing to get into a discussion.
Use this opportunity to find out what they don't like about your product and what aspects they do like about your competitor.
You may find that it's not the GUI of your competitor they like, it's some aspect of the functionality. Maybe your competitor's GUI doesn't hit the spot either, but it's closer than yours. Here is an opportunity to innovate and maybe it's actually very easy to do.
Just remember, sometimes there is a standard way of doing things and you just have to conform because that is what people expect. It's not copying.
The goal of any interaction with a potential customer is to get some benefit. The best way to do that is to keep asking questions.
What aspect of XYZ's GUI is better than ours ?
What are you trying to do with the software ?
How many swabbles do you need to process in one batch ?
Why is that particular data visualisation so important ?
We thought it would be easier to start that action with one dialog instead of two - why is two better ?
Drop all assumptions about what you know.
If two people say the same thing, maybe they have a point.
"Today a customer sent me a support email stating that my software is crap, that if I had designed the GUI like a particular competitor that I will sell more copies."
Some customers are just arseholes, I'm not sure if that's the case here but as Andy says you have to develop a thick skin.
However it may be worth responding, you could reply to the customer and ask them what part they are finding difficult to use or what feature is missing. Try and steer the conversation away from your competitor.
I'm not sure it's worth looking at your competitors sites, any idiot can clone a product and many will, do you want to be in that crowd or establishing your own identity.
If you want some inspiration try looking at good products from other markets and see what you can learn from them. For instance if you were writing event planning software then go and look at at the key products in the project management industry for ideas.
> He is not alone, I noticed that many of my customers are
> using the competitors product and are familiar with their
> GUI before switching to mine.
If they all think the competitor's GUI is better, then why are they switching to yours?
In fact, when you say "switching" to your software, do you mean *buying*, or just *trying*? That's a huge difference that matters to your question.
Also: *familiarity alone* makes people prefer things (cf. the "mere exposure effect"). My sister clings to America Online like grim death because it's what she has always known despite it being utterly unnecessary for her to use the web and email for about 10 years now. My point is, your GUI might actually be far better than your competitor's, but some customers will clamor for what they know, what is familiar. It behooves you to do whatever you can to know the strengths and weaknesses of each GUI, to separate the familiarity factor from the actual quality (assuming this is something that rises above mere individual preference--which I believe it does; Fitt's Law and all that are real).
It's impossible to offer good advice on something like this without knowing more specifics about the sort of thing they are talking about.
Is it that you can drag and drop a batch of files into their program to start something, but in your program you have to open them one by one?
Do they have sliders to set something but you have text configuration files only?
If not that, what exactly? You should be able to describe the mechanics of the usability issue without getting into what the program is or does in general.
Blind cloning is a bad idea since most programs are badly designed, so you end up cloning a bad design.
If there is something clunky about your program, which you know because customers are sending feedback (something most customers do not do) then that clunky thing probably should be redesigned or augmented. The improved design may or may not be a clone of the competitor, and whether it is or not should be a factor of whether you found that was the best solution in testing different approaches, not because it is anything to do with what the competitor is doing.
Do you eat your own dog food / have you personally tried the competitor GUI vs. your own, and/or spent some time with people who have used both?
My guess/experience is that if you do this with an open mind, you will change your tune completely.
Hopefully, whatever is better about your app vs. your competitors is a lot more than the GUI, like it calculates PI to the final decimal place or finds all possible prime numbers, or something cool like that.
@Scott - It's something like competitor designed theirs for processing one item after another, while mine can process one or all item at once. Steps required to complete actions on the competitors side is one less than mine.
@GregT - Thank you for the insight. I'll critically look into your suggestions.
"Steps required to complete actions on the competitors side is one less than mine."
Bingo! That sounds like a good place to start, if it is something your users would find valuable.
Wednesday, August 28, 2013
1/3 of your complaints are going to be that your app doesn't fit one users expectations/work flow, 1/3 are going to be that you do something different, and 1/3 are going to be that your UI sucks. Figuring out what bucket you fall into is the hard part.
I always try and ask for more info on what the user doesn't like as vague comments like "sucks" don't really help. You can't make everyone happy but before dismiss some one as a complainer you really need to try and figure out if it is a legit complaint.
I was drunk when I posted my last reply, so sorry for it sounding so peeved. But the gist of it is important: don't waste time wondering and refusing... just make the app what your user wants. Why would you hesitate to gain a paying customer? Don't think; just do.
I've bought iPhone apps after recommending features to the author who then did what I asked. If they hadn't, they wouldn't have my sale, nor would they now be getting my accolades and recommendations to all my friends.
>just make the app what your user wants
You are advocating significant development effort on the basis of feedback from one person, who isn't even a customer?
Thursday, August 29, 2013
I listen very carefully to what my customers say. Then I ignore >90% of it. If I did even half of what they ask for, my product would be a huge, rambling, impossible to maintain, hard to market, mess.
Thursday, August 29, 2013
Andy's comments are true. In particular, for someone frustrated with workflow, listen to the pain points, but ignore the specific design recommendations, as the user doesn't have the background to know the best solution to the problem.
There are rare exceptions though. For example, if you have a user that you know very well and he is an expert in the problem domain, and is also a designer himself. Where I can think of this happening in recent years the person isn't even a customer - it might be one of a couple of competitors that I chat with. We'll be talking about our design philosophies or bouncing ideas back and forth. In this case, if I like something he says I'll say, "That is a really cool idea because it does ABC in the least number of steps/very intuitive way. Do you mind if I steal it?" And he'll almost always say "Be my guest." Or vice versa. If it is some super secret thing though we won't discuss those parts.
I have some particular customers who will sometimes approach me with very specific things they need to be fixed added or changed, and they can explain in very clear reasons why the current design is deficient. These cases will be simply changes, not grandiose new features, and they won't be describing how to implement it, they'll just say something like "I really need the option to change this parameter to these other values because of this use case (that you've not considered)." Now, we get lots of requests from guys that don't really know that this will solve their problems and they won't. Those guys I ignore. But there are also the guys that have a history of doing cool things with the software and they only very rarely make these requests. With those guys I'll argue with them a bit to find out what they really need it for, and when it's convincing then I'll add it. It can't be for a one-off case that is some particular project they are working on, it has to be a general thing that is going to be helpful. Preferably it doesn't change the interface in any way at all and is a change under the hood. Or maybe some menu has one new item. But anything that adds to the complexity of the program - new windows, new fields, or even new checkboxes, should not be added casually at all since it will make the program worse for every single person who doesn't need that feature due to its mere presence increasing complexity and cognitive overhead. Any option you add, you have to realize that a good portion of users are going to randomly change that option to see what happens, and then leave it in a random state. If that random state is a bad thing you have a problem.
Perhaps you should make a video walking the user through the GUI and use that to show the user where things are and how the way to do things is different/better.
You can also make a migration guide/tutorial/video to your product for the key workflows, referencing the workflows of your competitors... "instead of working on one file at a time, start by loading all the files in the file manager", "from the file manager, click 'process' to process the selected files", etc.
Another way to help with the problem could be to create a search function like the one in Blender:
If you hit the space bar, a search box appears and you see all the commands matching the characters you type. I don't know what domain your software covers, but in case of Blender, if you don't know how to, for instance, delete an edge, you just type "del..." the "delete" command is displayed and if you click on that, you have the choice to delete different things like an edge or an object or....
This is helpful for transitioning users because it allows you support your competitors' terminology without changing your GUI:
Suppose that your software uses the term "Delete", but one of your competitors uses the term "Erase". Users look up and down your GUI to find the "Erase" function. They can't find it, so they look in your documentation and they still can't find it. If they are persistent, they search on Google or ask on a forum where someone will make them feel stupid for not knowing that Erase is called Delete. Now your GUI really sucks.
With a search system, you can easily implement synonyms "Erase (Delete = Ctrl+d)". Your customers search for Erase, find the function and at the same time learn that it the same thing as the Delete button that's been sitting in front of them the whole time. Worst case scenario they don't notice, but they can still access the function so they don't care.
You can also make a list of the words connected with tasks that need to be done differently in your GUI compared to your competitors and put some advice in your documentation using their terminology as keywords.
For instance, a Photoshop user learning Gimp is going to look for layer effects. What do you know? No layer effects to be found anywhere in the menus or in the documentation... but if you want a drop shadow, there is one in the Light and shadow filter, and bevels effects are found all over the place in different filters and scripts (Gimp GUI is poorly organized). With Photoshop being such a leader, you'd think that the Gimp documentation would have at least an entry for "layer effects".
There is even a "layer effects" plug in for Gimp... but nothing in the documentation to tell you it exists.
If Gimp documentation had a couple lines like "Layer effects: use filters for the most common options or download the "layer effects" plugin for more control", a Photoshop user would know what to do instead of scratching his head wondering why stupid Linux geeks think the Gimp can replace Photoshop when it doesn't even have the most basic layer effects.
Hope this helps.
Friday, August 30, 2013
@Sylvain Galibert The GIMP is open source, feel free to fix it :) I know what you mean though, really clever tech hidden behind a terrible UI. Maybe we can all take lessons from this.
Friday, August 30, 2013
"@Sylvain Galibert The GIMP is open source, feel free to fix it :) I know what you mean though, really clever tech hidden behind a terrible UI. Maybe we can all take lessons from this."
Yes, my point was not to put down The Gimp, but to use it as an example of a software which is in a very similar situation as OPs:
Many new users are already familiar with the GUI and workflow of Photoshop and can't find where things are in The Gimp.
Problem with The Gimp being free and contributed to by volunteers is that people work on solving their problems, they work on cool stuff they want. They aren't paid, why shouldn't they do what they want on instead of the boring *** stuff that does nothing for them?
Working on the documentation is not sexy. Besides contributors know already where things are, moving things around in ways they are not familiar with to please potential new comers who use a different software on a different platform - huh, sure, later, after they are done fixing all the stuff they want to fix, for them, if they have some spare time.
Not blaming them one bit. IMHO, that's one of the main reasons why we can sell software in spite of the fact that free, open source alternatives exist:
If our beginning users have problems with our GUI, we think "Gee, that's bad, I am losing money here. How can I help them get started, at least until they like it enough to pay some cash", whereas the open source equivalent is, "Lazy whining morons. Everybody else was able to figure out how it's done. Why can't they? Here I am, busting my rear end trying to improve this thing, make real features, and not only I do it for free but these lazy *** have the cheek to complain about it and want me to spent even more of my time for them. Don't I give them enough already?"
PS: I know a dozen important things I could do to improve The Gimp and I know the Gimp is open source, but just because I could potentially spend a few hundred hours learning how their code base work, learning what makes a graphic program tick, and attempt to reorganize it in a way that's a bit more accessible to most users (for instance, fix the fact that the right click does not provide a contextual menu on Windows) doesn't mean I want to do it. God knows I have enough projects on my plate without taking on something like Gimp for free.
Saturday, August 31, 2013
A screenshot is worth a thousand words. If we saw your UI, and perhaps your competitors UI, we might be able to say either your UI sucks, or your users are just being users.
Anytime you have multiple people giving you the same feedback, it certainly deserves looking into - which is what you're doing. That's good.
I've seen plenty of apps that are plenty powerful in what they do, but look like they were designed by someone with a DOS fetish - yet they're oblivious to the fact that their UI sucks, because they like it. I always keep in mind that I'm not writing software for ME, I'm writing it for my users. That doesn't mean they always get what they want, but it does demand consideration.
Saturday, August 31, 2013
>yet they're oblivious to the fact that their UI sucks
There is a reason for that:
Saturday, August 31, 2013
If someone can be bothered to email you saying your GUI is rubbish compared to a competitor
They are really saying :
Your Product does something that the competition does not do that we really value.
In fact, we value it so much we will even try and push you to improve the weaker part of your product.
If you DO NOT fix the GUI then they will email the competitor saying :
Your GUI is great and it is a shame that you don't do XX like Mike Johnson's product.
"Your GUI is great and it is a shame that you don't do XX like Mike Johnson's product."
This definitely happens all the time.
I have seen my customers trying to convince my competitors to add my features to their products. These customers will describe in immense detail how my stuff works and become free consultants to the company in cloning and testing to make sure it works the same.
I have also had customers try to convince me to adopt the competitors features. I prefer not to do that since it nearly always is a case of something that is wrong for my product as it serves a different customer class I don't want, or it is a feature mine already does a different way that they don't realize and the answer is just to tell them how to do it.
In any event, it's important to realize that there are customers who will try to spread novel and better features among competitors in a field.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz