What if there were a product that is exposed to you first in the simplest form. It's clean, elegant and simple. Easy and not intimidating to use.
As you use the product, your needs begin to increase and suddenly you need a new feature. As it turns out, the product actually supports this feature and so you turn it on. Now, you are turning on feature X, not feature package premium--just feature X.
In fact, the product actually has several additional features and functionality that can be enabled and disabled one at a time. None of these "extra" features cost "extra". They are all included in the base price of the package.
What if your product has a training module, where users can be guided through test use case scenarios that expose and demonstrate new feature modules. And what if we make it so that when you enable a new feature on the product, that feature only shows up to users who have completed the training guide for the new feature in the module.
In other words, in order for any specific extra feature to show up it needs to be:
1) Turned on by the administrator.
2) Flagged as "trained" on a per agent basis.
I worked with a large personal finance software company at a time when they were enraptured with re-use. They had visions of doing things like sharing contact and project management modules across customer relationship management (CRM) and invoicing applications. I had a large stake in making sure they thought through these issues clearly, as the very form of the product I was leading the creation of was at stake.
We think about an invoice or a project or a task or a contact as something that's fairly self-evident, but they're not. More precisely, an application needs to create a model of these things, and that model is a useful simplification.
It is likely that "a product that grows with you" is one that fundamentally changes the model of the entities that your product works with. So, for example, a simple invoicing tool might have a client or a customer field, and that works in let's say ninety-five percent of the cases, but for some people, they want a full-on contact manager where you need to know that an invoice is for ABC Co., that the client contact is John Smith, that invoices should be sent to [email protected]. Pretty soon you're going down the contact management slash engagement business process analysis rabbit hole.
And going down that rabbit hole is fine, but you're never going to be able to create 1. a simple, novice-friendly view of that industrial strength application that 2. stores data in a way that is semantically correct so that 3. when the user decides to upgrade from Invoicr Lite to Invoicr Enterprise Platinum their data isn't a nightmarish state.
This is one of the reasons why it took Windows user experience so long to approach anything even remotely as pleasant as the Mac: Windows had to support a much — let us say out of politeness — richer model computing than the Mac did. The Mac user was never exposed to certain details — like whether your filesystem was "really" hierarchical (the original Mac didn't have this feature) — but instead shown a simplified view of the world that Apple and developers had the freedom (and obligation) to implement by any means necessary.
/noob rant about the magic, magic!, of using emacs.
* Scripts such as keywiz let you incrementally improve your knowledge.
* Having a REPL in scratch means you can interactively tweak things.
IELM is more of a proper REPL, however.
However, I think a piece of software that evolves is what most people intend when they start with a minimum viable product. What you don't see too often are benchmarks to "grade" users and automatically move them up to more advanced features. I'd have to think more about it to see how it could be implemented and how beneficial it would be but I think its interesting none the less. It would be similar to a game in which you "unlock" certain maps/levels/etc.
Thats a fine objective for _some_ software. Twitter clients should be like that, the majority of what email clients or web browsers can be like that.
It's possible (probable?) that fully featured project management software can't be like that. There's too much external system level understanding required to expose everything the user needs to know about how and why to use the system in optimal ways to be able to encode it all in beautiful UX/UI.
Try and work out, as an exercise, how you design a UX/UI for a git client that'll allow a cvs or subversion user to "pick it up with ease". Some things "just don't work that way", and I'm reasonably sure project management, at least at medium and large scale, require user training (whether formal or self-trained-via-google, or through many iterations of trial and error).
_The Humane Interface_ discusses the balance between delivering something with "optimal usability" from an objective and scientifically validated standpoint vs. delivering a product the target audience can quickly familiarize themselves with and transfer their existing domain knowledge to.
So, while the Canon Cat may be a revolution in word processors, the average user will do better with something similar to Microsoft Word because they know it and can apply what they already know rather than learn a whole new way of word processing.
If you're performing a complicated task, it's reasonable to ask that the software not make the task harder, but it's also reasonable to expect to have to learn how to use a new tool.
I suspect that project management (at least for some large projects) may be such a problem domain, where the tools are unavoidably complex.
The spreadsheet is a great example of something that is ridiculously intuitive when you first use it, and grows with you. From inserting values in cells, to formulae and UI features like freezing, to advanced constructs like pivot tables, and ultimately to programming.
I would call that a smooth UX trajectory from novice to expert.
From experience, I think mandatory training is necessary otherwise you end up with your agents using fields as they _think_ they should be used instead of how they should be used.
this approach was tried by Gnome's Nautilus for a while, a few years back... and it failed miserably. It feels to me like a bad excuse for not designing a good UI in the first place...
Tony Mobily http://www.apollohq.com
"So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback."[2]
While you could argue that some products appeal to certain segments (unexperienced users vs more experienced users), there still is no reason why you couldn't use that customer group and refine your existing product, create a secondary product (addition), or a new one entirely focused to that 'other' customer group. In this example, a new product focused to the more experienced user might be easier as that is exactly who you focus on for an early adopter group.
[1] Eric Ries "Harnessing the Power of Early Adopters" http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2291 [2] http://www.startuplessonslearned.com/2009/03/minimum-viable-...
It seems that Pro Am and Pro are separate market segments that marketeers have difficulty positioning.
The reason is that people fancy themselves as being more competent than they actually are, and would go out and buy the souped up version that has features they could not possibly need (like 12 simulataneous cameras) and look like a space shuttle cockpit instead of something simpler.
This is an interesting problem. I wonder what could be done about this? You'd virtually be forced to name the actual professional edition as something rather staid, like "Final Cut Classic" in order to properly sell your product.
Adding features is hard work, risky, expensive, and sometimes counterproductive (!). It's hard work, because you need to change an existing, working piece of software with new code, and deploy it. Including possible database changes. It's risky. Deploying a new version of your software might introduce nasty bugs, huge usability problems, or you might change the way things worked before, actually displeasing a lot of users. It's expensive. Programmers aren't cheap. Then you need testing, QA, ticket triage... all things that cost a lot of time, and money. Counterproductive. Your new features might only benefit a tiny portion of your userbase, and might not attract new customers. They might break your existing model. And so on.
Once you've reached a good feature set, doing continuous development is more of a life choice, rather than a business decision that makes sense.
Really.
Tony Mobily http://www.apollohq.com
http://www.frugalmarketing.com/dtb/corevsring.shtml
Perhaps the OP developed a core competency in project management, which requires a different app. Spool implies that it is hard to have an app that can meet the needs of both core and ring users, since they have different needs.
It's not novice vs expert in the app that matters, but novice vs expert in the domain area.
Tony Mobily http://www.apollohq.com
As users gain more experience, their needs become slightly more complex. They start to understand the simple product completely, and then they have the cognitive ability to understand more fancy bells 'n' whistles. For users who have been doing project management for a long time with any software product, they will have a long list of things that they know -- from experience! -- that they need.
That is why there's a market for simple and there's a market for full-featured. Both are discrete markets, usually. Obviously every software designer strives for "power made easy" -- it seems easy at first, but there is power under the hood when you need it.