Meanwhile, I've been designing author assistance software for almost 10 years. Though I've learned a lot about product development, the following is doubtlessly one of the most important lessons I've been taught:
To be successful with software, it is not enough to have a good idea or to solve a problem.
Congree is in a relatively comfortable position. We develop and market a product that is virtually indispensable in large and medium-sized enterprises and that enables an impressive ROI of one year or less. Nevertheless, we often notice that this is not sufficient to close a deal.
It's somewhat like physical exercise: Of course I know that exercise is good for my health and can even extend my life. However, I still prefer spending the evening in front of the computer and watching cute kitty videos on YouTube. I know the problem, and I know the solution, but I'm not willing to take up the challenge, because I don't consider it to be as interesting as watching kitty videos.
A few years ago, we started thinking about how we could engage users and potential customers more effectively and stimulate their interest in our software. We realized that this would be possible with more intuitive, more attractive software that delivers a clear benefit as well as a feeling of satisfaction.
So we visited customers, organized conferences, and conducted surveys and workshops, hoping that this would help us to model the software in such a way that more potential customers decide to tackle existing quality problems with the help of an author assistance tool.
Actually, the customer feedback helped us to identify some points, which we have also taken into consideration in the software. However, we also found out something that surprised us:
Users are often unable to describe their requirements.
Users often fail to give the answers on whose basis the product could actually be improved. In fact, we need to be careful not to make the product a bulky, unwieldy software monster that lacks the features needed to create enthusiasm. Of course, this is not because users don't have good ideas. Definitely not. Rather, the problem is the line of reasoning that many users understandably follow:
"My wishes are far too utopian to be mentioned. I don't want to waste anybody's time."
"Perhaps the software already contains this feature and I've just missed it or not read the manual carefully enough."
"Technically skilled people could consider my idea to be naive."
"He's so nice. Why should I bother him with too many demands? Perhaps I should save up some of my ideas for another time."
"Why should I make the effort and describe my problem? Nothing will be done anyway."
"I want to be able to click X to make Y happen. Everything else is nonsense."
"I know what I need. But I can't explain it. He simply doesn't understand me."
"I'm not a user, but I know what my team needs."
"I've been using the software for some time. Actually, I've got used to its functionality."
"I'm no software developer. How should I know what is feasible and what not?"
"I'm in charge of purchasing the software. I wouldn't want it to appear incomplete."
As you see, "why not just ask" seems to be the obvious thing to do, but might not necessarily result in dazzling software. The best ideas could even remain hidden. The result might even be something that could have been solved in much more convenient way.
But what are the alternatives? Without user input, the product development will eventually drift away from the target group. How can the software be improved in such a way that it not only delivers added value, but makes users feel comfortable and happy to use it? For this, you need to abandon your ego and put yourself in the user's position, far away from your own opinion and experience. Today, this approach is called "empathic design".
Empathic Design
Empathy is the human ability to feel what others feel. It enables us to understand their pain or joy and react accordingly. This ability can also be used in the field of software development and especially for the development of user interfaces.
Emphatic design is not only based on the collection of requirements, but on the wishes, worries, and tribulations that can be read between the lines. These requirements are often conveyed to us in an unspoken manner, e.g. by means of gestures, facial expressions, or actions.
Indications of this kind can be collected through dialog or by means of observation and analysis. The central question at the back of our mind should always be: What does our user really need, and what will make him or her happy?
Learn How to Listen
A support request or an improvement proposal usually describes a specific problem for which the user needs a solution. First, the problem is described ("right now, the situation is as follows"). The requirements are derived from this description ("in the future, this is what it should be like"). The troubleshooting measures follow this order, and specifications and phone calls also reflect this two-step approach. However, we can extract even more from this type of communication:
- We can learn how the software is used.
- We can get an idea of how serious the user considers the problem to be.
- We can see which software features are particularly important to the users.
- We can realize whether the user is a supporter or a skeptic.
We can then use this information to solve the problem and to approximate the software to the expectations and mind-set of our users. After the conversation, it would be beneficial to take notes and think about the points discussed.
Show Me How You Work and I'll Show You What You Need
The optimum approach would doubtlessly be to observe the user during his or her work, either via video or directly on site. I've had several opportunities to accompany authors for a full workday. No verbal feedback is as valuable as seeing how a user uses your software. Here are some of the issues you will certainly witness:
- Functions are misunderstood and thus misused.
- Functions are misappropriated.
- A solution is built around the software in order to solve a certain problem.
- Side effects occur in connection with other software or certain hardware components.
- Users regularly change the default configuration.
- Users use some features rather infrequently (= they are not accustomed to them) or very frequently (= they are familiar with them).
You can then react accordingly and streamline the software, add features, make the software more compatible, and adjust the development focus. While doing so, ask yourself: "What will these changes make better for the author, and how will this increase his or her satisfaction?"
Empathic design is not always easy to achieve and does not come without cost. It takes a lot of time and energy. You need to know how to listen and be willing to do so. To achieve this, you need to be a good observer and be keenly interested in and curious about other people. You need to be able to suffer with the user when software problems arise. However, the positive results in our software must not be overlooked. Congree is more fun for our users, it is being used more intensively, and it sells faster than any of our predecessor products. Truly, software development needs what politics and private relationships also need: a little bit more empathy!
