8 Comments

  1. Terence

    It’s better but not optimal.

    Without the real world incentive of a commercial budget and an ROI development focus, projects will always be casually managed and waste people’s time.

    No one person is responsible for the cost involvement because everyone is paying the bills. This shows up in the casual direction-setting that let “Features-as-Plugins” waste so much of everyone’s time, energy and cost.

    Simply to transition [rename] Into “Features-as-Projects” isn’t the solution in and of itself.

    A much better approach is to have a more focused way of thinking out loud before direction is set. And the conclusions should be tested before anyone starts writing code of any description, except perhaps for a wireframe or two.

    Perhaps a useful proxy for figuring out which projects should get the love ~ and which should get the order of the boot ~ would be to crowdfund them all and see who is willing to put their money on the line for this or that feature/enhancement/fix/whatever?

    And by the way, this problem has been around for years and not only in the open source world. Stuff gets developed by clever developers who found it interesting to develop, but when they saw only a handful of people installed it, didn’t want to support it over the long term.

    Which is one reason why the repo has so many dead bodies.

    Changing the name is good, so long as the focus shifts to thinking and market testing before doing.

    Report

    • Jeff Chandler

      Did you read the part about design and discovery? Basically, it’s what you just described and is the primary focus of the way it will work now. From Helen’s post:

      “Proper discovery will allow for testing long before functional development begins using low-fidelity storyboards and walking through potential concepts with users, both verbally and visually. Projects should check in at a meeting when discovery results are available and continue to check in through the design process.”

      Report

      • Terence

        Yes I did Jeff.

        In fact it was the bit about “Feature design and development should come from interviews with users, developed personas, surveys of those personas, documented flows, and other fairly standard methods,” that worried me most.

        If you ask someone if they like something they can say yes or no for dozens of different reasons. If you ask them if they would buy it, you will get the same inaccurate answer. But if you tell them, this is the price, please press the “Buy Now” button, only then will you find if you have a winner.

        This illustrates my point precisely. There is no ‘real world’ involved when its not commercial, requiring someone to achieve an ROI, or just you’re asking people for an opinion.

        Which is why I suggested crowdfunding as a proxy for buyer intent.

        Report

      • Helen H-S

        “Feature design and development should come from interviews with users, developed personas, surveys of those personas, documented flows, and other fairly standard methods” is essentially the same as “thinking and market testing before doing”. I think there may be some disconnect about what “discovery” means here. We should be discovering people’s needs and workflows – we can’t ask them if they like something if we don’t have that something yet.

        Report

      • Terence Milbourn

        What I am getting at is that people very rarely tell you the whole story and often they make up a narrative that suits the occasion or what they think the need to provide in the circumstances. Most of which will often send you off in the wrong direction. What is needed is a proxy for gauging or validating buyer intent in the real world, which is why I suggested crowdfunding.

        Report

  2. dac

    Perhaps a useful proxy for figuring out which projects should get the love ~ and which should get the order of the boot ~ would be to crowdfund them all and see who is willing to put their money on the line for this or that feature/enhancement/fix/whatever?

    Report

  3. Morten Rand-Hendriksen

    This is the exact methodology we used for the ImageFlow project, and it resulted in new discoveries of how people use and understand WordPress that hopefully will make their way into core at some point in the future.

    The new procedure outlined is the only way we can build solutions that actually work for and the way the people who use WordPress want and need them to. The plugin-first approach of the past can easily lead to passion projects driven by assumptions. By implementing user testing, UX, and feasibility studies in the beginning, we can produce better solutions that work for more people.

    Report

Comments are closed.

%d bloggers like this: