Forgot your password?

Who should have the most input into software redesigns?

Displaying poll results.
The users using it
  11305 votes / 52%
The engineers building it
  3298 votes / 15%
The UI/UX folks designing it
  1886 votes / 8%
The managers organizing it
  222 votes / 1%
The marketers selling it
  299 votes / 1%
The people who whine on the internet about it
  1941 votes / 9%
Leave my software alone!
  2593 votes / 12%
21544 total votes.
[ Voting Booth | Other Polls | Back Home ]
  • Don't complain about lack of options. You've got to pick a few when you do multiple choice. Those are the breaks.
  • Feel free to suggest poll ideas if you're feeling creative. I'd strongly suggest reading the past polls first.
  • This whole thing is wildly inaccurate. Rounding errors, ballot stuffers, dynamic IPs, firewalls. If you're using these numbers to do anything important, you're insane.
This discussion has been archived. No new comments can be posted.

Who should have the most input into software redesigns?

Comments Filter:
  • by sylvandb (308927) on Tuesday April 16, 2013 @04:10PM (#43465589) Homepage Journal

    The only correct answer is "it depends."

    What is changing?

    Is it a UI/UX redesign? Then users and UI/UX experts.

    Not user visible? Then the engineers building it.

    New feature? Users and marketers but the engineers need input into the schedule/impact.

    Managers if any, allocating resources and schedules are always involved.

  • by thoromyr (673646) on Tuesday April 16, 2013 @04:13PM (#43465647)

    sounds reasonable to me. In reality there isn't a "single choice" the way a poll like this presents it, but I've had the misfortune of having to use too many "engineer designed" applications to want them anywhere near specifications or user interface design.

    And the poll does say "software redesign" implying it is coming from an existing base. Features are worthless if they aren't used and coherent users can be invaluable in determining what would be useful to implement (unlike the seeming majority of incoherent users who think a bug report is "how to ask for usage help" or want the staples "that was easy" button implemented).

  • by Anonymous Coward on Tuesday April 16, 2013 @04:37PM (#43465959)
    Although that sounds like a reasonable position - it is how we got Windows 8 Metro. A bunch of dilholes in a focus group were somehow lead by the marketers and UX people into saying that they wanted the same UI on their computer as they wanted on their tablet. Of course they didn't want that - nobody really does. The UX people told the engineers what to build and the engineers shrugged and built it.
  • Users are morons (Score:5, Insightful)

    by gman003 (1693318) on Tuesday April 16, 2013 @04:57PM (#43466163)

    If I'd listened to what the users *said* they wanted, I'd have a pile of self-contradicting systems, dozens of near-identical hardcoded reports, and a UI with more menu items than some restaurants.

    If I'd listened to marketing, the front page would have more widgets and dials than a Formula 1 car, and we'd interoperate with every possible system, dating back to the 80s, and we'd have yet more repeated systems.

    As it is, I have to creatively "forget" the stuff that management insists on that serves no purpose, and half of our features end up cut because they tell the site guys one thing, and the core guys another.

    Oh, and because our UI guys never *use* the site, I end up able to design a better UI than they do. We started a complete redesign of the reports system, with some rather major changes, and the comp the UI guy came up with was basically the old comp with a few more fields (ironic, as one of the biggest complaints was that there were too many fields, many of which were not always needed).

    What you do is *listen* to the users, then give them what they want instead of what they say they want. Placate marketing by making one of the new features more fancy-looking, with graphs or some shit.

  • by Anonymous Coward on Tuesday April 16, 2013 @06:51PM (#43467263)

    that shit for the next 10 years.

  • by blackcoot (124938) on Tuesday April 16, 2013 @08:20PM (#43468017)

    You're asking the wrong question, as I've learned the hard way. The question you ask your users is not "what do you want", because obviously the answer is invariably "a pony and a cake and a million dollars and world peace." I've had much better success with "tell me about how things work today", which very quickly gets the conversation centered on pain points --- what is, from the user perspective, broken or otherwise less usable and friendly than it should be.

  • by gadzook33 (740455) on Tuesday April 16, 2013 @10:26PM (#43468785)
    The iPhone was not built by asking users what they want. It was built by clever engineers solving a problem. Users don't know what they want or what is possible and there is no way to short-circuit or work around this fact.
  • by Anonymous Coward on Tuesday April 16, 2013 @11:10PM (#43469035)

    And as a phone user I hate the iPhone. It's not the be-all and end-all Jesus phone as many people make it out to be.

  • by tconnors (91126) on Wednesday April 17, 2013 @01:57AM (#43469705) Homepage Journal

    All redesign work should go through the UI/UX folks responding to the users' needs.

    I strongly believe that form follows function, but without real consideration to how users will be using the software the user interface can seriously impede the actual function. Some engineers can be downright sadistic in their UI designs.

    UX folk are why we end up with Microsoft Windows 8, the Ribbon interface, lack of menu bars, Gnome 3 and Chromium ("no, you can't have middle-click-selection-opens-URL-contained-in-copy-buffer, because that's too confusing for the lusers!"). They should all be dumped into a vat of boiling Hydrofluoric acid.

  • by mjwx (966435) on Wednesday April 17, 2013 @03:35AM (#43470005)

    I strongly believe that form follows function,

    You really need to look up this phrase.

    It means a buildings appearance should be based on a buildings intended purpose (I.E. an apartment block looks like an apartment block, not a crushed coke can).

    This is precisely why we shouldn't let UX people have the most say, because UX is a bollocks field invented by marketers to cover why their product was designed using principals contrary to well proven HMI/HCI. They beleive silly things like removing features makes user interfaces simpler.

    but without real consideration to how users will be using the software the user interface can seriously impede the actual function.

    This is what UX designers do, create unreliable and very difficult to use and decipher interfaces. If you want a product that is truly sadistic, let UX people overrule engineers.

    How to run a a product development project.

    0. Get the users to tell you what they want.
    1. Get the engineers to look at this and tell you what is possible.
    2. Get the managers to look at what's possible and tell you what's in the budget.
    Engineers are the most important. Everyone else will plan for the impossible to be magically done. Then managers because everyone else will plan for the impossible to be paid for.

    Seriously, UI designers and Marketers should have no part of the planning process. UI's should be modular, not integrated so they can be changed separately (as their own project), button spacing and interface colours should be planned last, making a working product comes first. Even output can be converted from what the engineers made to what the UI designers think is more friendly. OTOH, a good UI cant make a turd not smell. A marketers job is to sell what you've got, not go on flights of fancy about what you could make.

    Let UX/UI take precedence, you end up with Windows 8.

    If you want an example of how a bad UI doesn't kill a product look at Total Annihilation, a RTS from the 90's. Absolutely craptastic UI, terrible on all counts. I cant emphasise how bad the interface is on this and it's not like it was the infancy of RTS by a long shot. However Total Annihilation is one of the best RTS's ever made, why... Well the gameplay was just that perfect it overcame the woeful UI and bad graphics. It was such a good game, it still sells.

  • by Hognoxious (631665) on Wednesday April 17, 2013 @04:42AM (#43470223) Homepage Journal

    Involve the end users in the design, but don't let them do the design or you end up with something like this [wikia.com]

  • It Depends (Score:5, Insightful)

    by kramer2718 (598033) on Wednesday April 17, 2013 @11:51AM (#43473153) Homepage

    On the goal and nature of the redesign.

    If the goal is to improve usability, then the customers should. Of course their input should be focused through the UI/UX guys.

    If the goal is to increase profitability, then for B2C software, marketers and for B2B sales.

    If the goal is to improve the maintainability and stability, then software engineers.

    If the goal is to improve operability, then the operators.

    If the goal is to improve scalability, then capacity planners and enterprise architects through the lens of software engineers.

  • by youngatheart (1922394) on Wednesday April 17, 2013 @09:02PM (#43478793)

    I recently had the (mis)fortune of managing a small project from start to finish. Here's how it should have gone:
    Business Requirements -> UI/UX design -> Development -> Review and Revision -> Implementation

    Here's how it actually went:
    Business Requirements (BR for brevity) assuming advanced (impossible) AI -> UI/UX/Dev meeting -> New realistic BR -> UI/UX/Dev mockup and approval -> Development Committments made -> Solution approved by UI/UX -> Implementation and Financial Committments made (with new BR "minor adjustments") -> UI/UX/Dev meeting to explain why BR "minor adjustments" are impossible with Implemented Solution -> Blame, paper trails, resumes updated, late night cowboy coding -> New Solution -> UI/UX/Dev meeting results in UI/UX "minor adjustments" -> Emergency Spagetti Coding -> UI/UX/Dev meeting results in UI/UX "minor adjustments" -> Much Balmer Peak coding, Terrifying Debugging -> UI/UX/Dev meetings results in UI/UX "minor adjustments" -> Spagetti code disassembled, rewritten for sanity (more late night Balmer Peak coding) -> UI/UX meetings finally result in a final stable Soution

    I adamently wish I knew how to adjust the process so that the "should have gone" cycle would actually happen but there are hurdles I haven't found a way around because all too often:

    1. Business Requirements writers don't know what is really possible because they don't understand the data or programming possibilities
    2. Users don't know what they really want because they can only imagine what they already know with added buttons
    3. Developers commit to plans blind to what future changes will be required
    4. User Interface designers don't realize the limitations of development, the data, or what the users will actually do

Mr. Cole's Axiom: The sum of the intelligence on the planet is a constant; the population is growing.

 



Forgot your password?
Working...