Why "all-in-one" productivity tools confuse new users
17 comments
I think the key is the mental model, as you said.
One danger is trying to reduce multiple different concepts to a single concept. For example, instead of thinking about an email, a task, and a calendar entry as separate things, we could just have a generic concept like an "entity" which has attributes like a time/date or a list of people or a body of text.
Programmers love that kind of abstraction. We love having a few simple pieces that we can combine in various ways to get what we want. That is literally what we do when we program.
Normal people, though, hate that. Instead of giving them a tool to get their job done, we've given them a puzzle. They need to figure out how to combine the pieces. And what's obvious to us, is absolutely not obvious to them.
I haven't seen your UX, so I don't know if this is an issue, but I would focus on the mental model. As a user, what do I need to know to start using the tool? If that's more than a single sentence (to start) then you're in trouble.
I'm always happy to brainstorm with people. Hit me up if you want to chat sometime.
One danger is trying to reduce multiple different concepts to a single concept. For example, instead of thinking about an email, a task, and a calendar entry as separate things, we could just have a generic concept like an "entity" which has attributes like a time/date or a list of people or a body of text.
Programmers love that kind of abstraction. We love having a few simple pieces that we can combine in various ways to get what we want. That is literally what we do when we program.
Normal people, though, hate that. Instead of giving them a tool to get their job done, we've given them a puzzle. They need to figure out how to combine the pieces. And what's obvious to us, is absolutely not obvious to them.
I haven't seen your UX, so I don't know if this is an issue, but I would focus on the mental model. As a user, what do I need to know to start using the tool? If that's more than a single sentence (to start) then you're in trouble.
I'm always happy to brainstorm with people. Hit me up if you want to chat sometime.
> Normal people, though, hate that. Instead of giving them a tool to get their job done, we've given them a puzzle
On the other hand, highly integrated or opinionated tools need to be both easy and flexible enough to fit existing models/processes or it will simply overwhelm new users. Or it has to have some other benefit that is significant enough that users are willing to change their models/processes.
The spreadsheet is a great example. The core mental model is extremely simple: it's the same as a paper spreadsheet but you can put calculations (formulas) in a cell. That's it! That's the mental model.
Once you go beyond that model, people get confused. What's a pivot table? What's the difference between $A1 and A$1? Why is my date showing up as a number?
But it works because 80% of the people only need to know about the basic mental model. If you try to reduce email, notes, meetings into a single mental model, then you're back to the puzzle problem and people have to solve it to do even the simplest thing.
You may or may not remember Lotus Improv, which was effectively a reinvention of the spreadsheet. In Improv, the core mental model was the pivot table, which allowed you to do some amazing things (e.g., "add up the sales for each quarter by product type"). But even the simplest things required people to understand the core concepts of a pivot table (columns, categories, rows, etc.). Tech people loved it. Normal people, not so much.
Once you go beyond that model, people get confused. What's a pivot table? What's the difference between $A1 and A$1? Why is my date showing up as a number?
But it works because 80% of the people only need to know about the basic mental model. If you try to reduce email, notes, meetings into a single mental model, then you're back to the puzzle problem and people have to solve it to do even the simplest thing.
You may or may not remember Lotus Improv, which was effectively a reinvention of the spreadsheet. In Improv, the core mental model was the pivot table, which allowed you to do some amazing things (e.g., "add up the sales for each quarter by product type"). But even the simplest things required people to understand the core concepts of a pivot table (columns, categories, rows, etc.). Tech people loved it. Normal people, not so much.
As a user, yes, as a developer no.
If it helps: As a user I don't want an onboarding process, I want to be able to start with the features I need. The I can later migrate more and more stuff into your app. If it's an all or nothing deal, then it's to much work to get started.
I think this is also why we see people jump on "simply solution for X", then X grows and users adopt the new features in slow progression. At some point it become to much for new users, and they start searching for "simply solution for X" and the cycle restarts.
If it helps: As a user I don't want an onboarding process, I want to be able to start with the features I need. The I can later migrate more and more stuff into your app. If it's an all or nothing deal, then it's to much work to get started.
I think this is also why we see people jump on "simply solution for X", then X grows and users adopt the new features in slow progression. At some point it become to much for new users, and they start searching for "simply solution for X" and the cycle restarts.
IMHO it is all part of the documentation to enable people to up ramp.
What is missing from most documentation is simple Use Case.
You need a video / tutorial that is JUST 'Wheres the starting point'
Then one addressing what you expect most people to do.
Each tutorial should be no more than 5 minutes, ideally 1 minute. (hmm sounds like breaking up your code into manageable parts)
Making it easy to find the tutorials is important.
If one tutorial needs another, then point to it. Do not just say "before you start make sure you understand quantum theory"
You know this is like the 'one man band' where the person is playing a dozen instruments. "I do not understand, you know how to read music, why don't you strap this on and perform?" Er I don't know how to play the xylophone.
Ok let me teach you each instrument.... then we can put it together. Here is the symbol, here is the harmonica, we will just integrate these 2.
Hope this helps.
What is missing from most documentation is simple Use Case.
You need a video / tutorial that is JUST 'Wheres the starting point'
Then one addressing what you expect most people to do.
Each tutorial should be no more than 5 minutes, ideally 1 minute. (hmm sounds like breaking up your code into manageable parts)
Making it easy to find the tutorials is important.
If one tutorial needs another, then point to it. Do not just say "before you start make sure you understand quantum theory"
You know this is like the 'one man band' where the person is playing a dozen instruments. "I do not understand, you know how to read music, why don't you strap this on and perform?" Er I don't know how to play the xylophone.
Ok let me teach you each instrument.... then we can put it together. Here is the symbol, here is the harmonica, we will just integrate these 2.
Hope this helps.
> What is missing from most documentation is simple Use Case.
Microsoft's strategy was simple: have vertical specific SMEs, sales teams, and solution delivery teams that build solutions that addressed specific use cases for those industries. Life sciences, legal, manufacturing, you name it: Microsoft had a vertical specific team that understood the use cases in those verticals. Their sales teams configured vertical specific demos. They shipped vertical specific templates and configurations for those use cases.
I ended up in life sciences (pharmas, biotechs) by happenstance and we helped customers get SharePoint configured for use cases like operating clinical trials on SharePoint.
The underlying platform is incredibly generic, but having your sales people speak the domain space and pre-configured solutions (or solution delivery partners) made it more palatable.
I think most companies that are building these kind of tools need an "on-ramp" that is industry or use-case specific designed with SMEs or customer observations for those use cases.
I wonder if that is why it worked as opposed to why it sold. At least, as one of the users in that time it seems to me that the itch was the document repository with some features, and the rest was fluff for purchasing to sign off on.
All the calendar, task, website stuff ended up dying away, because what we really needed was a good document management system, with optionally some simple signoff loops and notifications.
That was great. Yes, it was just unix like tools with a window. That is the craigslist of os improvements.
It really was the use case, but the simple one. I saw plenty of power users try to do complex and ultimately fragile uses that died away.
In the case of this user, I love the idea of turning an email to an action, but I also need to add that to my action board and assign it, and check people time, at which point the simple action only makes sense for individuals, not teams or orgs. and I need to add a couple missing actions, and summarize. So suddenly the all in one is a marginally useful tool that is also a straightjacket. And then I go back to outlook and jira and excel and trelli or whatever.
All the calendar, task, website stuff ended up dying away, because what we really needed was a good document management system, with optionally some simple signoff loops and notifications.
That was great. Yes, it was just unix like tools with a window. That is the craigslist of os improvements.
It really was the use case, but the simple one. I saw plenty of power users try to do complex and ultimately fragile uses that died away.
In the case of this user, I love the idea of turning an email to an action, but I also need to add that to my action board and assign it, and check people time, at which point the simple action only makes sense for individuals, not teams or orgs. and I need to add a couple missing actions, and summarize. So suddenly the all in one is a marginally useful tool that is also a straightjacket. And then I go back to outlook and jira and excel and trelli or whatever.
> All the calendar, task, website stuff ended up dying away, because what we really needed was a...
I completely agree, and I will add one more thing: when you change how the product looks or works, make sure that users - especially inexperienced users - can easily find the documentation and tutorials that correctly describes the version of the product that they are attempting to use. I would guess that out of ten people who run into a situation where something does not work as described, maybe only one or two will push through the frustration and go on to become power users.
> “…uncomfortable: the more integrated a tool becomes, the harder it is for people to form a mental model.”
Some of this sounds like reinventing the wheel. This conclusion, for example seems obvious, other than the uncomfortable part, which is what users might use to describe their experience with an unfamiliar model and no clues from the software. How is this insight different than, say, how a programmer feels about an unfamiliar API or custom classes?
If there is a design to the software then some explanation might be needed to give users the keystone idea. After that I would argue it’s UI and UX design working to communicate to the user what is possible, and how you go about doing it.
With that in mind, this conclusion:
> “People rely heavily on familiar UI metaphors (tabs, inboxes, folders).”
Speaks to me same as, programmers rely heavily on documentation and pattern (not anti-pattern. lol…people rely heavily on words and syntax to communicate).
The story of the 1990s web with the introduction of Macromedia Flash, saw a world of fantastical UIs. Some were brilliant, some were obvious, others were inscrutable puzzles. The backlash with Web 2.0 washed all that away, and it all became _familiar UI metaphors (tabs, …)_.
Knowing what I know today, I wonder if the key to an advanced workflow isn’t a hybrid of scripting and UI. Most great ideas arrive ahead of their time.
Some of this sounds like reinventing the wheel. This conclusion, for example seems obvious, other than the uncomfortable part, which is what users might use to describe their experience with an unfamiliar model and no clues from the software. How is this insight different than, say, how a programmer feels about an unfamiliar API or custom classes?
If there is a design to the software then some explanation might be needed to give users the keystone idea. After that I would argue it’s UI and UX design working to communicate to the user what is possible, and how you go about doing it.
With that in mind, this conclusion:
> “People rely heavily on familiar UI metaphors (tabs, inboxes, folders).”
Speaks to me same as, programmers rely heavily on documentation and pattern (not anti-pattern. lol…people rely heavily on words and syntax to communicate).
The story of the 1990s web with the introduction of Macromedia Flash, saw a world of fantastical UIs. Some were brilliant, some were obvious, others were inscrutable puzzles. The backlash with Web 2.0 washed all that away, and it all became _familiar UI metaphors (tabs, …)_.
Knowing what I know today, I wonder if the key to an advanced workflow isn’t a hybrid of scripting and UI. Most great ideas arrive ahead of their time.
I'm personally not a fan of these "super" apps that lock you into vertical silos. I noticed that Google Chrome on Windows dropped the ability to share a link via an external email program, preferring you to use GMail. Microsoft Edge is the same - wants you to log into your Microsoft account. Separating apps by function is freedom.
I'm on the hunt to build such thing (https://tablam.org + "excel" + "access OR fox pro", ...) and I have never consider the "all in one" a paradigm for end-users.
As you discovered, is for you as the tool maker and for your power users. On top of that, let's say you make "widgets" or "mini apps" that are built on top.
ie: You make Django, but you ship: Shopping cart, Blog, Wiki, each with their own UI and App branding
As you discovered, is for you as the tool maker and for your power users. On top of that, let's say you make "widgets" or "mini apps" that are built on top.
ie: You make Django, but you ship: Shopping cart, Blog, Wiki, each with their own UI and App branding
I had the exact same experience with my web app, about 10 years ago.
My conclusion was that productivity forums are more of a support group than a place to find users for new concepts.
I built an app that is 100% flexible to adjust to how you want to work, and I think most people expect such an app to tell them how to work and it has to be simple.
My conclusion was that productivity forums are more of a support group than a place to find users for new concepts.
I built an app that is 100% flexible to adjust to how you want to work, and I think most people expect such an app to tell them how to work and it has to be simple.
All in one products tend to have all mediocre pieces. That's not exactly an answer to your beginner-resistance issue. All in one systems also tend to make it hard to get bulk data out in a useable format.
I've only used a few integrated productivity apps and generally found them less useful to me than less integrated ones. The clearest comparison is Notion which has so many ways to store information that I'm always misplacing knowledge. The places where I can effectively store and retrieve knowledge is Google Drive/Docs or GitHub projects/issues/PRs.
I tend to also not like individual parts of an integrated productivity tool but everyone is expected to use most everything. Basically the bundled MS Teams problem. Integrated productivity isn't selling you the best of each, they're selling you the best integration of maybe-not-your-favorite tools. Just my hot take, YMMV.
I tend to also not like individual parts of an integrated productivity tool but everyone is expected to use most everything. Basically the bundled MS Teams problem. Integrated productivity isn't selling you the best of each, they're selling you the best integration of maybe-not-your-favorite tools. Just my hot take, YMMV.
My issue with all-in-one apps if they have a weak spot, the whole model breaks down. Outlook is an app that bundles email, calendar, contacts, notes, and to dos. The notes are trash and I never could cobble together a to do workflow in Outlook that made sense to me. So I have to go find separate apps for those functions, and then use Outlook for email and calendar while ignoring those other parts. This means I also need to actively ignore features to make sure I don’t do something that will start filling up the to do section that I’m never looking at. The end result is an app that feels bloated and trying to push features on me I don’t want.
With separate applications it is trivial to swap out one part of it. I use Apple Mail, Calendar, Contacts, Notes, and Reminders… but sometimes I want to use Obsidian instead of Apple Notes, or OmniFocus instead of Reminders. This is no big deal. The workflow doesn’t breakdown because of a single app being swapped.
The other benefit of separate apps is being able to work in multiple windows. Many all-in-one apps make it difficult to see different sections at one time. If it’s not an officially supported use-case, you’re out of luck. With separate apps, I can have whatever I want up and visible in any view I want.
> Have you built or used something that people love after trying it, but struggle to understand before trying it?
I think two things help here.
1. Even if there are advanced features, the application should be simple to pickup and use for someone who doesn’t know anything about those features, for basic functionality. Apple Notes is a good example of this. At its core, you can open it and jot things down and make new notes if you want. As you need more features they are there… better organization, formatting, note linking, various import methods, voice transcription, tables, etc. Some of this may be discovered organically and some of it may be learned by actively going to look for it. Obsidian also does this decently well.
2. Good documentation. When people do want to know more and step up their workflow, they need good resources. Text and video is good here. Not only a feature list and how to use said features, but also real-world examples to give people ideas of how the features can be used to make their life better/easier. At launch, you need to do this all yourself. Over time, if it’s popular, some creators might help with making content to show various use cases, features, etc. However, I’m still of the opinion that the people behind the app should have the best and most complete source of this stuff. I’m always frustrated when the vendor documentation is really bad or non-existent and I have to hope that some random person figured out what I need and shared it somewhere. There are a lot of popular apps like this, and I’m not sure how they ever got off the ground.
In a non-tech area, Ryder Carroll does a good job of this with the Bullet Journal. When you look at stuff random “influencers” make, it’s insane, more arts and crafts than productivity tool. When you go to the source of the guy who created it, he makes a ton of content and it’s all very pragmatic and down to earth. I think this is invaluable for making sure the influencers don’t turn people off by only showing over-complicated abominations. People making videos about Obsidian do this a lot as zettelkasten purists.
With separate applications it is trivial to swap out one part of it. I use Apple Mail, Calendar, Contacts, Notes, and Reminders… but sometimes I want to use Obsidian instead of Apple Notes, or OmniFocus instead of Reminders. This is no big deal. The workflow doesn’t breakdown because of a single app being swapped.
The other benefit of separate apps is being able to work in multiple windows. Many all-in-one apps make it difficult to see different sections at one time. If it’s not an officially supported use-case, you’re out of luck. With separate apps, I can have whatever I want up and visible in any view I want.
> Have you built or used something that people love after trying it, but struggle to understand before trying it?
I think two things help here.
1. Even if there are advanced features, the application should be simple to pickup and use for someone who doesn’t know anything about those features, for basic functionality. Apple Notes is a good example of this. At its core, you can open it and jot things down and make new notes if you want. As you need more features they are there… better organization, formatting, note linking, various import methods, voice transcription, tables, etc. Some of this may be discovered organically and some of it may be learned by actively going to look for it. Obsidian also does this decently well.
2. Good documentation. When people do want to know more and step up their workflow, they need good resources. Text and video is good here. Not only a feature list and how to use said features, but also real-world examples to give people ideas of how the features can be used to make their life better/easier. At launch, you need to do this all yourself. Over time, if it’s popular, some creators might help with making content to show various use cases, features, etc. However, I’m still of the opinion that the people behind the app should have the best and most complete source of this stuff. I’m always frustrated when the vendor documentation is really bad or non-existent and I have to hope that some random person figured out what I need and shared it somewhere. There are a lot of popular apps like this, and I’m not sure how they ever got off the ground.
In a non-tech area, Ryder Carroll does a good job of this with the Bullet Journal. When you look at stuff random “influencers” make, it’s insane, more arts and crafts than productivity tool. When you go to the source of the guy who created it, he makes a ton of content and it’s all very pragmatic and down to earth. I think this is invaluable for making sure the influencers don’t turn people off by only showing over-complicated abominations. People making videos about Obsidian do this a lot as zettelkasten purists.
What surprised me wasn’t the technical challenge, but the user reactions.
Power users absolutely love it.
They immediately get the concept. They think in workflows, not apps. To them, “summarize this and turn it into an event” feels obvious and natural.
But new users often freeze.
Even though the interface is technically simpler, they ask things like:
“What category is this tool?”
“Where’s the starting point?”
“Is this replacing my email or my notes?”
“Why doesn’t it look like a normal productivity app?”
It made me realize something uncomfortable: the more integrated a tool becomes, the harder it is for people to form a mental model. And without a clear mental model, onboarding becomes a wall.
A few patterns keep repeating:
People rely heavily on familiar UI metaphors (tabs, inboxes, folders).
Removing those reduces complexity for some users but increases cognitive load for others.
New users want “features”; power users want “flows”.
Integration increases value but decreases clarity.
I’m curious if others have run into this: Have you built or used something that people love after trying it, but struggle to understand before trying it?
How did you communicate the value? Did metaphors help? Onboarding flows? Videos? Something else?
Happy to share more from my experiments — I’d love to hear your experiences too.