Skip to Content

Simplification – Carrying it a little bit too Far ?

A frequent question is – how simple should things be ? this is with regard to implementing a solution with the right balance between complexity and functionality.  This would of course require the person to wear multiple hats – often leading to a collision course…  A typical scenario :- The current flow of events warrants that some one steps in to manually approve certain transactions that are above a certain value. When modeling the same into the system :  1. Do you go about modeling the same As-Is ? 2. Do you ‘Anticipate’ future requirements and build in the intelligence for the process to do an e-mail approval ? 3. Where does the business fit in to this picture…??  Modeling the process As-Is would mean that someone somewhere later on would definitely mention to the business that something like this is possible ( oops…)  Option 2 would require a lot of complexity by way of configuration , security , integration etc etc behind the scenes.  Option 3 is more far reaching when you have a technically marvelous solution that the users do not understand!!  Which one of the above do you choose ? essentially saying that do you promise the moon to the end user and go all out trying to give them the same resulting in ( not always but most of the time ) in a complex maze of interfaces that are tough to interpret and debug or simpler still.. give the user a simple configuration with the perceived message that further refinements in terms of user experiences are possible but would require a lot of technical jugglery and might impact the regular flow of events ??  Many a time the hat of a Business Analyst or BPX would prompt you to take option one whereas the Designer in you is screaming murder in terms of development effort and complexity .. which ones do you address?  There is an interesting quote from E.F Codd – the father of the RDBMS concept… Attempting to force one technology or tool to satisfy a particular need for which another tool is more effective and efficient is like attempting to drive a screw into a wall with a hammer when a screwdriver is at hand: the screw may eventually enter the wall but at what cost?         – Providing OLAP to User Analysis – Hyperion – 2006 The same applies to good design concepts as well especially when we tend to go overboard with simplification or trying to force one thought process for a requirement that does not quite fit the current design..  The question again comes to What do you do ? My 2 cents on the same would be :  1.Simplification is a long running thing and it could be looked at in a longer time frame compared to giving the users a working satisficing solution for now with the promise that further tinkering would be done post delivery. – This essentially achieves two things – one is to understand the user psyche as to what they want and what more do they want and another it that the client is aware that we are looking at further tinkering and the same could be rolled out with any further requirements / modifications.  2.The question that needs to be addressed is – are the users ready to adopt  satisficing solutions that address their immediate needs or is Business and IT deciding that users should get the best solution possible at the first shot – here a proactive IT business relationship goes a long way in smoothening things and also reinforcing the view of business that IT can deliver and the team is good at it.  Here the BPX would be a necessity by way of : 1.Adopting good design practices by donning the design hat 2.Controlling requirements – by adopting the business analyst hat.  All that needs to be done would be to effectively juggle the hats around and make sure things go on time and in full…
You must be Logged on to comment or reply to a post.
  • If anyone can be accused of forcing technology onto recalcitrant reality, it’s him.

    But back to the substance of your post.  The reason I think it’s a good one is because it deals with real-life, not wishful thinking.

    Too often, proponents of new methodologies assume the participation of “consenting adults” …

    • But then hes the one that started it all right .. but maybe if not him maybe someone else… who knows  but then found the quote pretty reminiscent of what we might have to face later… especially coming across systems that have had a singular view of simplification and dealing with upgrading / tweaking / rescuing these systems turns out to be a nightmare leading to question the noble ideals set forth in the very beginning..

      My 0.02

      • it’s by him, of all people.

        Anyway, I enjoy your perspective even if I don’t agree exactly with everything you say in all details.  So I hope you keep posting.


  • Very interesting issue to address. I do have a differen way of looking at it..
    Any config. or development is purely justified by the MATERIALITY of the issue?
    Simple Qs to ask yourself as you sit down with a pen and paper:
    1. How frequent is this business event?
    2. Is the pure basic simple requirement understood?
    3. Is it along the lines of Best Business Practices?
    4. In the design, can the solution features be identified as user ease and core functionality?
    5. What does the business lose if all the bells and the whistles are not delivered?
    6. will all the markets gain from this solution and can this solution eventually be rolled out to all with minimum localisation needs.
    7. Is there visibilty to where the buck stops???

    • Radhika,
      These questions are definitely important … as for what I was also talking about – is it fair to compare an existing tool / interface which could have evolved over say about 3 years and expect the same from the process being modelled and the interactions for the same.
      And in this regard – in keeping it simple – what should be kept simple – the process / the frontend / the backend?? the priorities for the same would depend on the person affected…
      Another point to add to your list could be :
      8. Looking back on the process and the way it is currently – how frequently is is susceptible to change
      As for 5) do we tend to overpromise on usability and end up delivering an extremely complex solution…

      My 0.02….