What you do when your app has too many features
About a year ago I took on the obligation of redesigning ActiveCollab. I had the freedom to work in an environment of mutual trust, free from hierarchy, and fully open to suggestions. I believe that’s what allowed us to really rethink and improve ActiveCollab, and make it the best possible project management software it can be.
I first had to come to terms with version 4, which created not a very attractive first impression: the not-so-comfortable user experience made it feel like it was a second-tier software.
Despite that, the sale behind ActiveCollab showed how viable its market position really was. Given that there’s only a handful of first-class software solutions for any purpose, it proves how hard it is to make a truly solid product — something that actually solves problems. From that perspective, I always had great admiration and respect for ActiveCollab’s success.
However, keeping a product profitable requires perpetual alertness and every short rest leads to a customer drop. In the case of ActiveCollab, the user experience (UX) was one of the most neglected aspects.
A51 (the company behind the ActiveCollab) primarily saw itself as a programming company — the design was an afterthought, something that stood in the way of better technical implementation. Eight years of working with this mindset lead to the state in which the application found itself — in need of a fundamental UX redesign.
The problem of too much functionality
I spent the first week trying to get a feel of the existing software and locating key user flows that were causing pain, also known as friction points: sources of frustration that occur while performing certain tasks. There were lots of them. This was mostly caused by too many options and features in the app.
It reminded me of people who never threw anything away and kept clutter lying around a house.
I had a friend in high school who lived in an environment like that. Sometimes we got together and made pancakes, but only twice at her place. When it was dinner time at her place, you had to search for a plate among the papers and recipe notebooks. The same cupboard held jam, a drill, and a blow dryer. For her, this was a well-ordered system which she navigated without a problem. But for any guest, this was terribly frustrating.
ActiveCollab 4 was a house where nothing had been thrown away for eight years. It was a robust, feature-rich software that people learned to love — but only after they got the hang of what’s where and how it’s used. But when competing with 20+ similar products — and the fact that most people give it about a minute before moving on — only a persistent few actually learn and use it.
There was a lot of insufficiently thought out functionality that kept piling over the years and cluttered the interface. It’s much easier to add features and create an illusion that the software is powerful than to actually invest effort, understand the needs of real users, and develop the product accordingly. As time passed, ActiveCollab has become a tool where one set of features was used intensely by everyone while the remainder only emitted noise.
We were looking at a considerable reduction here — but not in a way where you’d cut off a patient’s foot to cure a sore toe. We had to find a balance and fundamentally rethink how to solve problems. Metaphorically speaking, we needed to throw away everything from our neglected house, sort it out, put things to their appropriate place, buy some new stuff, and trash all the useless stuff — while taking great care not to throw away the family silver.
Both on paper and during our conversations, we used an ax as a symbol for obsolete features, which were prime candidates for throwing away.
Getting started with the redesign
It soon became clear to me how complex ActiveCollab really was. The biggest hurdle would be 8 years of legacy as well as the existing users that deserved respect. However, we needed to be brave and resolved.
A push that gave us the much-needed confidence was a survey we made. In it, the number one reason why users like ActiveCollab was the self-hosted option. They pay for the software only once and, more importantly, install it on their servers. None of the competitors gave that option. For clients like government institutions, an essential feature was to have full control over sensitive data. We can only guess whether they use it to organize maids or government meetings. But the fact is, ActiveCollab solves a problem that none of the competitors can.
From the design viewpoint, it meant that most of our users accepted the UX shortcomings in an exchange for features that were paramount to them. This gave us a leeway to solve functional design problems freely — not in a sense of “We’ll turn everything upside-down, and hope they’ll like it” — but more in a sense that we have a good knowledge of our users’ priorities so we have enough space to “rattle the cage”.
Methodology we used
I’m no stranger to long projects and on every single one, I was the sole designer. This time I was also the “UX Team of One”, which was very overwhelming for a project this size. I’ve probably made a couple of mistakes: it’s pretty exhausting designing the architecture and solving flows, while simultaneously creating a visual identity, illustrating, writing copy, and coding.
Another problem with the solo effort was that those mistakes had to resurface somewhere in the functionality and the look of the application. It’s almost impossible in a beast of this size to keep consistency in architecture, visual identity, code, and copy—and on top of that to take shortcuts. If I were to start today, I’d certainly ask for more help early on, even if it meant managing a team (which I don’t particularly like doing).
What helped tremendously was that I didn’t have to make all the decisions alone. Almost every major design decision was a collaboration and it went through validation from everyone who had access to the application and the design.
If you asked me what approach we used to redesign the app, I’d say we were inspired by Lean UX methodology. In theory, it means we’d create a small and functional design team, consisting of people with various expertise (developer, support, designer, client, etc.). This way the design would be democratized and we’d gain valuable insight into the problem from different angles. The team leader would have a role of a moderator who guided the design process. We’d have to come up with a prototype or a primitive product as fast as possible, so the idea is validated early on.
In reality, though, we adjusted this romanticized workflow to our specific work conditions where:
- People come and go at different times;
- There’s no rigid management or formal meetings;
- Collaboration relies mostly on tasks in ActiveCollab;
- People are already overloaded with their own work.
Strict adherence to those principles would be a frustrating change to a daily routine for most people. So basically we operated on a more relaxed variant of Lean UX.
The team that designed the application consisted of Ilija (backend developer), Goran (frontend developer), and me (designer). For the first 6 months, we worked in the same room. I used that period mostly to thoroughly understand the problems we were solving. There’s something called a “beginner’s mind” — a concept from Buddhism, but useful for all sorts of intellectual work. It’s where an inexperienced person, untethered by previous experience, “slaps” ideas around and asks questions from an amateur’s point of view.
Although I’m experienced at design, I had a beginner’s mind when it came to ActiveCollab and project management. This was useful because it cast new light on certain problems. It enabled me to ask tough (or often meaningless) questions and oppose existing design solutions. Our lack of hierarchy was crucial because there weren’t any restraints when you had to oppose someone who, as in my case, paid your salary. There also weren’t any restraints when it came to opposing the designer’s authority. We spent more than a year in heated debates (in a civilized manner, of course). Even though it was energy-consuming, it always gave results.
Design tools and processes
During our discussions on how something should work, I used pen and paper to sketch and note what we talked about. Paper is fast, but it only gives a superficial feeling; design in code is the slowest, but it enables a more realistic sense of interaction. A lot of folks try to push their solution for this problem, but there isn’t a general consensus on the best practice. I’m all for using what you’re most comfortable with in a given moment. My process was constantly moving between paper, Sketch, and code — depending what was the quickest in that particular moment.
Sometimes the clearest way to communicate with a developer was to leave comments on the design. Even though we talked all the time, the comments proved useful for me too to remind myself how something is supposed to work.
I established a visual language slowly. I think it’s totally wrong to force the burden of visual design early on. You’ll inevitably lose a lot of time dealing with details, icons, and colors — without solving bigger functional problems first.
On the other hand, when the team is small, working this way is more dynamic and can produce results faster than if the development was conditioned by procedures and segmented into phases. I haven’t dwelled too much on that aspect because my environment gave me the freedom to use the tools that suited me in the given moment, so I could quickly jot down an idea and develop it.
Goran made functional units from my Sketch designs. As we already had an API, we could make and test fully functional solutions quickly. Our Lean methodology meant moving fast, often only to half-finished solutions — without waiting and fine-tuning the interaction, or polishing static mockups. We couldn’t be 100% sure whether something is a good design, so we made quick prototypes and tested. Until it goes through the hands of real users, we can only make assumptions. Because of that, our first goal was to create a good-enough foundation, which would later be improved through actual use.
Icon drawing and illustration is an almost relaxing experience, compared to solving any UX problem. It always starts on paper in a primitive and quick version so I could catch any kind of direction, but I always fine-tune a specific style in software - in this case, Sketch.
Our version of UX research
Anyone researching UX techniques has to collect information to better understand the problem and lessen the uncertainty of potentially bad design decisions. We gathered ours in a moderately systematic fashion from combined sources.
ActiveCollab has been around for more than 8 years, so we had a valuable database on user expectations (and frustrations). People who pay for software care a great deal to contribute to its development and they weren’t shy to voice out their opinions. Our team’s job was to hear them out and judge whether something is a real problem, or a particular user is just very vocal.
For example, there were recurring cases where people called support with complaints like “ActiveCollab is too clicky”. That was a good indicator that many processes caused friction, lasted longer than they should, and there was a global problem with insufficiently optimized flow.
As both founders, Ilija and Goran were involved in support for many years, they had a precise insight into what needed attention. Armed with this information, they often opposed my urges to reduce parts of the application which my instinct told were too obscure or complicated. In situations like these — where my instinct clashed with their 8 years of experience — the fairest judge was the usage statistic. We obeyed the following rule throughout the design:
If a certain feature is used by less than 10% of users, it was a serious candidate for removal (or at least a thorough redesign).
Solving problems with JTBD
Jobs-To-Be-Done is a concept that has existed in business for 25 years, but it’s relatively young in the context of UX design. JTBD represents customized and verbalized versions of processes that have been present in design (in one form or another). At the time I started working on ActiveCollab, texts on this subject started appearing more frequently, by authors such as Alan Klement and others on the Intercom blog.
In a nutshell, JTBD consists of defining a job that a user would like to perform in a certain situation to fulfill their goal. A common problem in UX design is a wrong problem definition. Often teams design a solution based on wrong assumptions and come up with great solutions for problems that don’t exist.
In theory, everyone would love if there was a precise way to solve the problem on which they work. But the reality is, each new project requires its own specific process. I feel JTBD is flexible enough so it can be applied to smaller problems as well as colossal ones.
Adopting a simple JTBD matrix in the thinking process enables better problem definition and makes a good foundation for the solution. However, even though the matrix is simple in itself, it requires training. Sometimes it’s very difficult to understand what job a user needs to get done and make a job story according to that. I haven’t wasted too much time trying to formally document the design by writing job stories; I was guided by the core idea rather than the actual implementation.
We made a great breakthrough in the design when the functional version saw the light of day. All the half-finished sections didn’t actually have realistic usability tests before we’ve started using them in production. It took about a year to get to that moment, but we finally had our Minimum Viable Product.
In mid-November, we drew the line and said: “From now on, we’ll use the new ActiveCollab for all our tasks, discussions, and collaboration.” The application was in a horrific state. Half the things didn’t work properly, and the new visual design often looked worse than the old one. However, since people were forced to use the product in the condition it was in, useful and precise feedback started pouring in. Since we made a good foundation, we didn’t need weeks or months to improve — it was a matter of a few days.
A year and a half later
The new ActiveCollab is finally out. The feedback we get tells us that the application has changed its identity — from a powerful and feature-rich collaboration tool to a relatively simple one.
On one hand, that’s encouraging news — we managed to maintain and improve 95% of the previous functionality, doing away with too much depth and complexity while retaining all the power.
We expect new users will get a considerably better experience with the new ActiveCollab.
On the other hand, there’s a concern that this new identity will shake up the old users. But I have to believe that a more comfortable UX will ultimately be convincing enough to overcome these little earthquakes that are sure to occur after upgrading.
Still, there’s always room for improvement. Although market validation is on the horizon, we’re conceptually satisfied with the foundations we laid. A year and a half later, our house is safe, warm, and pretty solid. There’s no threat that the roof will collapse, but there’s still a couple of cables protruding from the walls. And the interior isn’t exactly Scandinavian.
Great work is yet to be done.
First sketches of what's to become new ActiveCollab identity. That openness and simplification we strived to achieve through UX - we want it to come through identity too: powerful project management for all.