I’ll admit, I get concerned when I hear about a solution that tries to “do all the things.”
They never do them well. You are lucky to get it to do ONE thing well.
Think about the bloated enterprise solution you are likely using.
How many things is it trying to do?
How many of those things does it do well?
If that application does anything well, it is likely the thing that solution as.
For instance – back when I was implementing and training Electronic Health Records (paper –> computer), the system I worked with tried to do everything a medical office would need. Doctor’s notes, blood pressure tracking, appointments, prescriptions, etc.
What did it do well? Prescriptions.
Where did that system start? As electronic prescriptions.
You can do the same evaluation with any other enterprise system. What is the one thing it is best at? Likely, that’s where that system started.
As the flexibility of a design increases, the usability and performance of the design decreases. – William Lidwell
This is very much related to Feature Creep.
To accommodate for those different, often conflicting, requirements – designers and developers frequently resort to adding features.
More features = more complexity = more cost.
More complexity = less usability
Lidwell provides 5 questions to determine whether flexibility is worth the trade-off.
- Is sub-optimal good enough?
- Is the performance environment stable?
- Are performance and user requirements similar?
- Can the functions be modularized in the design?
- Does the value of flexibility justify all of the trade-offs?
The answer to ALL of these questions needs to be “Yes”.
Otherwise, you are looking at high costs and a high probability of failure.
An international non-profit wants to create a highly flexible “shopping cart” that allows their field units to sell items in any combination and at any price for any duration.
Memberships, event tickets, sponsorships, product, subscriptions… the products and services commonly provided by non-profit associations.
The more flexible, the better.
The constraint is that the solution has to accommodate their existing enterprise system.
On the surface, this does not seem like an unreasonable request.
Dig further, and there are issues.
- In practice, the processes for sales, tracking delivery and recognizing income are very different for each type of item (memberships, even tickets, sponsorships, products, subscriptions, etc).
- Different countries have different tax laws. Activity in some countries make selling in those currencies unstable. Think Brexit. Nevermind the fluctuations in exchange rates.
- The enterprise system they are using is designed and optimize to sell each type of item separately. The vendor did this to accommodate the different processes each type of item requires.
Let’s apply Lidwell’s Flexibility Trade-off evaluation.
- Is sub-optimal good enough? Likely, No.
- First, they need to be willing to define optimal. Then, they need to determine the acceptable level of sub-optimal to be able to answer that question.
- Is the performance environment stable? No.
- They are in the process of re-defining memberships + there are some international tax law and currency changes that will impact the design + there is debate as to what they are going to sell.
- My concern for the organization is that this project is a way to avoid having some really difficult conversations. Overdue difficult conversations around what the organization does and how they want to provide value to their members.
- Are performance and user requirements similar? Yes.
- Users want the solution very simple – pick, choose, price.
- Performance needs to be quick.
- It all goes through the same system.
- Can the functions be modularized in the design? Yes.
- Thankfully, the functions are already modularized.
- Does the value of flexibility justify all of the trade-offs? Unclear.
- I think the organization needs to do a very hard look at their current metrics around what they are selling and MEMBER feedback. Not the whims of the internal stakeholders who THINK they know what members and prospective members want.
- If this project manages to result in a solution, I recommended that they take a look at the resulting data to see whether they come close to returning the investment.
- Did they attract new members that they would not have obtained had they not created this endlessly customizable shopping cart?
- Has the renewal rate and participation rate among existing members increased as a direct result of this shopping cart?
- Do these numbers compensate for the project spend and the increased operational complexity?
Early cost estimates already made this project expensive. I think those estimates were low.
I rejected this project.
The likelihood of me being able to bring in this project even remotely on-time and on-budget with any semblance of quality was low.
Even the vendor has grave concerns.
The solution likely requires a major re-engineering of their product. The request is in direct conflict with the core assumptions the current enterprise system is designed around.
This vendor is also the top player in that industry and it does not appear that there many other options for solution development.
Even the usual third-party players are hesitating.
I hope the client proves me wrong.
The links below are Amazon Affiliate links. Thank you so much for supporting this blog.
Universal Principles of Design, Revised and Updated: 125 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach through Design