16 ms·

I just had an idea that might explain why this happens. Firstly, I've observed a phenomenon when I talk to a programmer about a problem I want to solve. They m

I just had an idea that might explain why this happens. Firstly, I've observed a phenomenon when I talk to a programmer about a problem I want to solve. They might get excited, learn a bit of the problem domain and then go off and build something that kind of solves part of my problem. But then I'm stuck in a endless cycle of explaining the rest of the problem, to someone who isn't really interested, then waiting for a new iteration and then evaluating how it doesn't completely the solve the problem until the programmer gets bored and goes off to find something new and exciting to do with computers. Programming the computerwas always the end for them. They don't actually care about the problem. I care about the problem. So for me computers are a tool to solve my problem. I might as well write the program myself because it's less work to become a mediocre programmer than to intimately understand the problem. My theory is that something like this happens in interface design. There are designers who love to create beautiful designs, and we love that, but beauty is the end of it for them. They don't actually care about the problem that the program (website, app, whatever) is supposed to solve. If they were stuck in a job filling out forms all day they would quickly learn the lesson to put the reset button out of the way. If they were intimately familiar with the problem, the better design would be obvious. And so it is that people with no "design skills" can point out the obvious mistakes of the designers. It's also true that good design is hard. Starting with a blank sheet and creating something, let alone something good, is daunting. Perhaps the hardest part is having the humility to admit, "I don't understand the problem sufficiently" and the empathy to care about the problem enough to learn it well.

pier25 6y ago
I've seen that too. UI designers not realizing UX is way more important than aesthetics.
- jevgeni 6y ago
  I think partly it is because UX is measurable (“A is less usable than B and thusly bad”), whereas aesthetics are not (“different tastes”). A kind of means to escape personal emotional accountability.
  - TeMPOraL 6y ago
    The problem is also what we do with the ability to measure. Typically, we're making easy things intuitive, and difficult things impossible. This is exactly the wrong way to go about things, if you care about delivering value to users[0]. We should be making the easy things easy, hard things possible, and forget about the whole intuitiveness thing. There's this widespread belief now that software is only good if a user who never saw it before can become proficient in it in seconds to minutes. I think this is one of the most devastating, dangerous ideas in computing. The only way you can achieve a learning curve like this is by removing almost all functionality from software - make it so dumb that it really takes only a minute to figure it out entirely. Sadly, this is what we see in mobile and web applications these days. What worries me here is that we've conditioned everyone to assume software is immediately and fully discoverable. Nobody is expected to read the manual these days, and so manuals are not provided, and since manuals are not provided, any feature that cannot be made apparent without explaining it in the manual goes away. (Even with kitchen appliances, the situation isn't that bad. When a person sees a particular appliance for the first time, they do read the manual, or get someone to show them how to operate it. Maybe it comes with the fact that buying appliances is expensive and overall a hassle, whereas software is too easy to procure?) -- [0] - I highlight that condition, because it's my belief that most software vendors don't care about delivering value to users. They care about making money off users, and there are many cheaper ways to do that than creating a truly useful and ergonomic product.
    - jevgeni 6y ago
      This is a great insight, thank you! I *try* to make my software initially intuitive and gradually discoverable. I think a gentle learning curve is better than a completely flat one. I thought quite a bit recently about the problem that you are talking about (diminishing end user value in software). I think the source is that we have a lot of devs and designers whose only experience is designing for maximized conversion rate or maximized engagement. As opposed to professional software. They have no habit of designing for value. And *that’s the culture*. Go to any awwwards gallery - all of the websites or webapps mentioned there are essentially ads with minimal content. Which isn’t too bad, since it leaves a market untapped through the collective arrogance of the incumbents...
- deleted 6y ago
  [deleted]
phendrenad2 6y ago
This is exactly right. I also see this from programmer side-projects. The programmer finds a new cool idea, makes a MVP, then gets bored and moves on. Github is a holding yard for such things.
- TheAceOfHearts 6y ago
  Nothing wrong with writing simple side-projects and moving on, that's an excellent way to learn. Not everyone can afford to donate a bunch of their time in maintaining a project for free, especially considering it's often such a thankless task. The fact that the code is available means someone can fork it and make their own changes and improvements.
- dgellow 6y ago
  It’s not necessarily about getting bored. The research/experiment process can be the goal in itself. Not everything is about building a finite product.
msla 6y ago
This is the kind of thing project-based courses ought to train programmers to expect: Yeah, you're a legitimately good programmer, but programming mostly comes down to solving other peoples' problems, so you can't rest on your laurels. There's a whole, wide world out there of companies that need bespoke software, and most of the actual effort in writing that code is ensuring it properly enforces the business logic of a business you know nothing about. Therefore, in this project you'll be helping a professor from some non-CS department write educational software. You have to balance accessibility with pedagogical accuracy, as guided by someone who doesn't secretly know that some specific algorithm is the magic key to solving the problem.
- chii 6y ago
  There's a 2nd order problem, where the stake holder doesn't actually know the requirements until they see a sample implemented. "I'll know it when i see it" style. This is often the case, with bespoke software. If the stakeholder has such a clear vision of their end result, they probably won't need you to help them implement it!
systemvoltage 6y ago
I partially agree that designers love to create beautiful designs and they don't care about the products. This is giving a false complacency to what outta be a tight intergration between design + developers with an oversight from the product owner. It is simply inexcusable. We're actively creating a culture of disregard/complacency/ignorance by not shedding light on this as a huge problem in UX/UI design. I want more people to make noise about this.
LaundroMat 6y ago
Your comment makes me think of the distinction Simon Wardley[1] makes between Pioneers, Settlers and City Planners. The former are the ones who get excited by making something new (and not solving the problem), the latter are the ones who get excited by making sure things keep running flawlessly. I do believe there are programmers for every category though. [1] https://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...
- microtherion 6y ago
  Kirk McKusick had a similar metaphor around road building, with some people hacking a path through virgin jungle with a machete, some bulldozing the road, some paving it, some adding lamp posts, and some painting the lamp posts.
atoav 6y ago
As someone who both designs and programs for the better part of his life, nobody is really safe from that phenomena. If programming and designing is communication this is akin to go "let me say something", sprouting an interesting point, leaving the inplied punchline hanging and exiting the room while ignoring the reaction. If it happens once, okay — if it happens all the time, maybe you should do something about it. The thing is: both design and programming are more often than not messy when things get real, but every programmer wants to create clean and beautiful code and every designer wants to create aesthetical designs. Many intuitively perceive this "beauty" to be in tension with the complexity of the problem that needs solving. The goal of programming and design is however not to create beauty, but to solve problems and do so beautifully and clearly communicate these solutions, because it doesn't matter how beautiful your code/design is if nobody understands it. Beauty is the cherry on top that you get to achieve once the cake below is done, tastes well and puts a smile on the faces of all the party guests. If you are good you might already plan the cherry into the shape of the cake at the very beginning — but confusing the cherry for the cake IMO means you are either not there yet in terms of your profession or the thing is a toy project to try things out specifically — which is totally acceptable if everybody involved agrees and totally egoistic and shitty if they don't. Don't agree to serious projects you are not willing to commit to once the initial interest fades. Really good designers are about integrating both usabilty and aesthetics in an iterative process, and do so in such a way the problem is solved, and solved beautifully, all while reducing the cognitive overhead needed by users. And this cognitive overhead is really what should drive us. The work of programmers and designers is so beautiful/dangerous because it multiplies to a thousand people for a thousand hours. Our decision affect people on a daily basis. Removing a papercut might seem like nothing, but if it avoids irritating even ten other people who use that thing 10 times a day, isn't it the obvious thing to not half-ass on, not to toy around with? Btw. Design that is only about aesthetics is something that I call "styling" maybe we need a similar word for programmers who toy around?
- TuringTest 6y ago
  > If programming and designing is communication There's a research field called Semiotics of Human-Computer Interaction studying user interfaces from that angle. Developers usually have a technical background from maths or engineering, and often are not aware of the importance of linguistics in our field. Both programming languages and GUIs are languages (artificial, sure, but linguistics also study those) which are used to write expressions that can be read by humans. Semiotics, the study of signs and their meaning, provide methods to analyze how users make sense of the software artifacts (products and tools) delivered to them. One researcher called the user interface a designer's deputy, i.e. a messenger that conveys in its entirety a message that the programmers wants to communicate to the users. This deputy must stand on its own, since it's the only information available to the user. Users then perform sense-making on the symbols in the interface, to infer the meanings of all elements [1]. Notice that the user can't see what each interface element actually does, since they don't have access to the code; they can only guess what it does from the available symbols. If the symbols lead the user to infer an incorrect meaning, communication breaks. [1] https://blog.prototypr.io/how-semiotics-can-help-us-in-ux-on-deconstructing-experience-eaf3e55fb0e1 https://blog.prototypr.io/how-semiotics-can-help-us-in-ux-on...
dgellow 6y ago
I sympathize with what you’re saying, though I would like to point one thing regarding your first part: writing software is sometimes a way to wrap your mind around the problem and think about it. When trying to solve something new I like to start writing code early on because that gives me a canvas on which I can start drafting ideas. It’s more concrete than a whiteboard but can still be very abstract and flexible. That’s how I identify what I understand and what I don’t.
thom 6y ago
It’s always been notable to me that the thing that killed Flash wasn’t the wars with the usability community 20-odd years ago, it was the iPhone. People dumped these garish interfaces because a beautiful device came along that refused to run them, not because they were in many or perhaps most cases terrible for the task at hand. I think a lot of the methodological knowledge built by usability people has probably been ignored in favour of a metric-driven approach these days. That approach is very good at identifying bottlenecks in existing workflows or deciding between two ideas, but ultimately lacks the empathy you describe. You can only really build that by engaging directly with users, and watching them suffer at the hands of your creations.
- matsemann 6y ago
  I've always felt it a bit weird that iPhones quickly became the norm for all designers I've worked with, them hailing it as a so great to use. While I'm stuck not knowing how to find stuff, it's always hidden behind some undiscoverable swipe gesture. The home button used to have 10+ or so different functions based on context. They way you touched the screen (click, long press, 3d touch or whatnot) mattered. Do normal users know all this? Or do they just only use the 10% easy functionality of the phone and is happy with that? Maybe articles like "17 Things You Didn't Know Your iPhone's Home Button Could Do" is a sign usability has been sacrificed in order to have a clean&neat design.
  - rkachowski 6y ago
    I have a half-baked still-gooey thought about this, but it's really around the time of the iphone (and the take off of the smartphone) that discoverability got thrown in the trash. Search bars instead of menus became the primary means of interaction, and ironically you can only find something with the search bar if you already know what you are looking for. Of course menus don't translate well to touch devices, and menu systems can quickly become unorganized junk drawers for functionality, but it feels like discoverability was never fully solved on touch devices.
    - bentcorner 6y ago
simonh 6y ago
This is why in so many problem domains, especially outside technical problems for IT people, proprietary software is the only option, or the only complete option. The best way to ensure people pay close attention to those last areas of fit and finish, and make sure they get attention from people with the different sets of skills needed to do a good job in all of those areas, is to pay them. That means you need a really solid revenue stream, and initially need enough capital up front to get the project going. I know, there are open source business models which work for some companies and that's true but generally in the sorts of technical problems for IT people. Compared to the IT industry as a whole those are edge cases. They seem more important to us embedded in the IT industry, but compared to the overall multi-trillion dollar global IT industry they're peanuts.
- danjac 6y ago
  > proprietary software is the only option, or the only complete option. If only that were true. I've watched a completely non-IT person work with both vanilla Gnome 3 and Windows 10; they found the former far more intuitive and unobtrusive (not looking at the individual apps, just the basic desktop UI). Proprietary design-by-committee doesn't necessary make for better solutions: hence the numerous complaints recently from people (often with accessibility issues) trying to book vaccination slots on government websites.
- chaos_a 6y ago
  This is why most linux distros have interfaces that are missing minor features and can be frustrating for users who don't have command line experience. For example, why can't I easily make a shortcut in ubuntu? Or how about the fact that you can't get full file paths shown in the default file manager, I often know what directory I want to get to but have to figure out what maze of folders I have to go through to get there.
  - practice9 6y ago
    > Or how about the fact that you can't get full file paths shown in the default file manager, I often know what directory I want to get to but have to figure out what maze of files I have to go through to get there. Did you mean MacOS?
bottled_poe 6y ago
This is a great comment which concisely expresses my own thoughts on the topic. Junior developers could learn a lot by absorbing this insight.
harryf 6y ago
Also sometimes it’s the process a team working on a design follows. Tried to illustrate this long ago about mobile hamburger menus https://medium.com/@hfuecks/so-we-went-with-a-hamburger-menu-a69a2d24075b https://medium.com/@hfuecks/so-we-went-with-a-hamburger-menu...
koonsolo 6y ago
I think you're missing a few steps in your development process, or at least one. Normally it goes like this: problem->solution->implementation->testing. Each step has a role associated with this: user->analyst->coder->tester. If you go straight from problem to coder, you shouldn't be surprised that you don't have a proper solution, because nobody really made a proper solution. That's like building a house without an architect. Hire an analyst.
- hulitu 6y ago
  Testing is hard. That's why they let it to the user.
  - _pmf_ 6y ago
    If I know that the user changes what he originally wanted, damn right I give the thing to the user instead of wasting effort on perfection and edge cases that get thrown out.
- tonyedgecombe 6y ago
  I don't know. The projects I got involved in that had an analyst involved tended to have reams of documentation for the obvious features, completely missed the non-obvious features and was wildly wrong in parts. This is what agile was created to solve. It was an acceptance of the reality and an attempt to live with that rather than trying to bend it to your will.
  - koonsolo 6y ago
    Even agile teams need someone who analyses the solution. If there is nobody who specifies the solution, you get what OP describes. Agile does not exclude different roles, on the contrary.
- 411111111111111 6y ago
  Most corporations aren't big enough to warrant dedicated personal for these roles. And if they are, it often ends with impossible to implement/maintain designs.
obscura 6y ago
This sounds like a flawed development cycle. Where's the end-user testing? In defence of the developers/programmers, many people are really bad at explaining what they want, not least because it's often not what they actually need. If a designer is designing something that looks good but doesn't work well (i.e., solve the problem), they are bad at usability/UX. They should be getting user feedback on their design before it's implemented - that's what user-centred design is about. There's often a gap when it comes to understanding requirements - between the end-user and the developer, between the designer and developer, etc. Requirements gathering is actually a specialised skill and one of the key duties of a business analyst.
myth2018 6y ago
I agree and I think your ideas form a good model to explain so many issues we've been facing more and more often. Some days ago I wrote here in HN about the change my stock broker made on their default home broker. It immediately becomes obvious that the people responsible for that design have never performed anything nontrivial with stocks. They created a symmetrical, colorful platform. The symmetry is enforced, therefore you don't have the flexibility of setting up your quote-boxes any longer (perhaps because that would break the artist's concept). Just to mention one of many issues the new design brought. The same applies to the Google Meet example in the article. Functionally, you'd never want those buttons presented that way. But placing them like that makes them look nice and symmetrical and Gestalt-related stuff, so that's the way to go and deal with it, dear users. > Perhaps the hardest part is having the humility to admit, "I don't understand the problem sufficiently" and the empathy to care about the problem enough to learn it well I agree, but don't see that happening, not in the short term at least. I had an argument with a designer some time ago about how much longer the project was going to take and how her ideas were actually substracting value from a user perspective. But she ended the discussion with a "this project has my signature, my reputation is in there". And that's what my criticism against current UX trends is all about. Artist's concept trumps user needs, project maintainability and everything. They are investing all the resources on graphic design matters and this is obstructing the whole field. Some UX folks argue that designers like those "aren't true UX designers". I agree, but those "false" designers seems to be outnumbering the "true" ones. The latter may eventually have to found a new discipline.
sriku 6y ago
There's a certain corollary effect to what you describe that perhaps applies to "modern" interfaces (both web and native desktop/mobile). Concurrency is excellent as an idea for systems design but horrible for user interfaces. Nothing seems to provide a stable interface and some concurrent process considers it it's privilege to suddenly modify a list of things I'm choosing from .. resulting in the items shifting just a few milliseconds before I click or tap my choice, which results in the wrong choice. This shift happens not only in vertical lists, but also tab-bar style buttons. To be precise concurrency isn't to blame for it, but it's more like laziness. The interface elements should be locked in place if the system detects that I'm about to select something. Whatever else is waiting to show up can wait, because I obviously didn't need to know about them a few milliseconds earlier.
- KajMagnus 6y ago
  > items shifting ... before I click ... results in the wrong choice Or a window from a different app pops up (the app took a while to start), steals the Enter key press, interprets Enter as "Yes do [something]", and then does it (but I didn't want that!). Why can't OS windows be click & mouse disabled for 2 seconds, after they open
nipponese 6y ago
Not sure why the designer always gets the blame here. The Product Manager set the requirements and sign off on the designs.
- yen223 6y ago
  One thing I learn from hacker news is that it's never the software engineer's fault
- tomxor 6y ago
  If the product manager dictates UI and UX design then they are the UI and UX designer and their title is meaningless. But what I think you really mean is that people are often in a blame culture that strategically puts up responsibility defenses which distracts them from producing a good result and focuses them on red taping to cover their asses. It is quite possible in these organizational structures to produce absolute shit and tick all the boxes and get everything approved and make sure no one in the position of actually doing stuff gets blamed for anything. Not saying that it's their personal fault that certain companies are that way, but it is possible to have some self respect and march back up to the manager and say hey this is shit and we should do a better design rather than waste time on this (ok, yes in a more articulate and respectful way) - if you think that risks your job then it's probably going to be more fruitful working somewhere else anyway. Disclaimer: yes I know real life has other restrictions that means not everyone can do this.
bsanr2 6y ago
I think it's simpler than that, in this case. What OP is describing is essentially a *control panel* (a small interface of grouped inputs for common tasks). This is an artifact of engineering design, where physical space and materials are usually at a premium, both in construction and usage. Once you've designed and built your controls, that's it; there's no spiriting a secondary interface out of thin air. However, with dynamic display-based interfaces, you can do just that. Much as I tend to loathe Apple's design, the way they handle iPad shutdowns is quite good: first, you press a button; then, the entire display changes to focus on this task. If you want to shutdown, you then have to perform an entirely different gesture to confirm. This layering of visual feedback and input types escapes the control panel paradigm and correctly takes advantage of the freedom that act lends to better communicate with the user. Unfortunately, doing so often means eschewing standards and best practices to find a solution that should work better for users. That is extremely difficult to get right; it's not very surprising that designers would purposely decide to use a flawed but known model instead. We need to get it out of our heads that designers only do things because they're visually satisfying. They are making purposeful and critical decisions to meet a design objective.
killtimeatwork 6y ago
> There are designers who love to create beautiful designs, and we love that, but beauty is the end of it for them. They don't actually care about the problem that the program (website, app, whatever) is supposed to solve. They're essentially aestheticians, not designers. Yep, I hate them too.
prox 6y ago
You literally described my job, I bridge the gap between design, code and make sure there is a thorough implementation of both, I have skills that overlap in those areas and so I can advise clients properly for any gaps that might have arisen. My bible is About Face : Interaction Design.
- mst 6y ago
  Speaking as a programmer who only occasionally interacts with design and considers himself largely terrible at it, reading "About Face" is probably the single book that helped the most to make me (slightly) less terrible.
  - prox 6y ago
    It is always good to hear this! Especially the part about smart products and posture is very good to know by heart. So many apps still just botch their posture or completely forget the users intent and context (if they even consider it!)
    - mst 6y ago
      I'm afraid I probably still botch it. But About Face has at least helped me to try not to.
- tootie 6y ago
  Haha, yes! And that book is pretty ancient. I think the first edition dealt exclusively with building Windows desktop apps because the web wasn't ready yet. It lays out some of the blindingly obvious UX axioms that a lot of devs just don't bother to think about. One of them is "hide the ejection lever" (a metaphor for the ejection lever on a fighter jet) for exactly the kind of thing MJD is discussing. Have those irreversible, destructive controls be present and findable, but really hard to click by accident.
  - prox 6y ago
    Haha, great example! It has had some revisions, my copy is from 2014, but the great thing is that it all remains relevant. The big takeaway is that humans shouldn’t be required to think like computers when they are interacting with one. “Warning : Failed to load library” <ok> Why did the library failed to load? Why are we being informed? Why does it say “Ok” when it is not ok? As a lovely example. And on the regular you still have these problems. The daily wtf is full of current day examples.
collyw 6y ago
I am beginning to think that hiring for enthusiastic programmers might be a mistake. Get on old cynical bastard like me. I just want to make my own life easy, and that means writing the easiest to maintain code that I can. Not trying out some new tech that has promised to solve all my problems.
danjac 6y ago
I think at one time there were a number of designers who transitioned from the print/magazine/brochure world to the web. They tended to prize "pixel perfection" and aesthetics over UX and functionality. This way of thinking is fine for making static landing and marketing pages, but is very counter-productive when you are building user-friendly, interactive and responsive applications. This is opposed to people who are actual UX experts who know how to trade off asethetics with usability.
- austinjp 6y ago
  There certainly were, I worked with a bunch of them. They were all talented, came from print and shifted to web + print. My job was to turn their gigantic Photoshop files into hand-crafted HTML, usually tables to layout carefully cropped and compressed JPEGs, and form elements :)
- asoneth 6y ago
  This mirrors my experience as a UX designer coming from the usability side. Many graphic design refugees are interested in learning about usability, user research, heuristics, Fitts' Law, GOMS/KLM, etc. But it takes time and energy. I've found that some small companies with no established UX team start out gravitating to shiny portfolio examples and end up putting visual design (VX) folks in charge of interaction design which sometimes goes poorly e.g. https://medium.com/intercom-inside/the-dribbblisation-of-design-406422ccb026 https://medium.com/intercom-inside/the-dribbblisation-of-des...
  - danjac 6y ago
    "Too many designers are designing to impress their peers rather than address real business problems." This has its parallel with the developer world, where tech choices are made to impress the peer group (including those in other companies likely to be hiring you) rather than address the business problem at hand.
throwaway316943 6y ago
I think the problems with creating a working solution run both ways. I’ve been involved in many design sessions where the subject experts didn’t understand how to make their envisaged product useful to their audience. It’s a common problem in programming as well, you can write code that performs well and is correct but the interface is such a mess that it’s completely unusable by anyone else. If someone is designing for beauty alone they’re caught in the same trap, the composition will work well by itself but its purpose will be unintelligible. Producing a good design requires working with all parties involved including the end users.
Nasrudith 6y ago
Architects - of the original building sense have a similiar misplaced emphasis problem being more about appearances and "advancing the field (read: novelty)" than functionality. Brutalism was an infamous example for making downright needlessly depressing buildings to live and work in that don't even save on maintenance in spite of eschewing ornamentation. Other fun foibles include putting the duct work on the outside of the building, the mold trap that is Fallingwater, and accidentally having a skyscraper melt a very fancy car with its glare before they had to sandblast it away. It is kind of a tautology to say it but this hints at it being a human organizational social issue behind the pathology if it keeps cropping up. I agree that good design is hard and often involves substantial work beyond just making something on the sheet.
j-krieger 6y ago
You're describing me and my ''kind'' of programmers very well. I try to make myself interested in your problems. However, most of them seem really ''otherworldy'' to me or are in a domain I don't care about about. I became a programmer because I like the art of the trade, and I keep myself interested by writing interesting code.
daveswilson 6y ago
I like that theory. It may explain why the Google Workspace (/G Suite/Google Apps) icons are now so indistinguishable. If one looks nice, why not make the others look just as nice?
valeness 6y ago
I think it's important to note that product lead, system architect, and UX architect are distinct roles, each with distinct responsibilities, for a reason. It's not my job as a coder to care about your problem past what has been described to me. It is your job, as product lead, to care about the problem and design a sufficient information architecture, subdomain map, and other documentation to model your problem. This goes both ways. It is not your job to care about my problems past how it impacts the product. I don't expect you to know or care about how we design the software or how it is implemented; whether we use snake or camelCase, if we use openssl or pgp, if we choose mysql or postgresql. I just think it's important to outline that much of your comment can be applied in the inverse, and saying that "It's less work to become a mediocre programmer than to intimately understand the problem", is the same as saying "It's less work to become a mediocre product analyst than it is to intimately understand how to code". I agree with your last point, it's important for every department to have humility and empathy for the problems of their peers. But, it's not a problem to be figured out by designers and coders; it's instead an issue that extends further and requires effort from everyone involved, and at every level, to support.
- creeble 6y ago
  I agree here. I think a big part of the problem, even in big companies, is that those roles blur too much. In particular, it is frequently the case where a product lead says something like “we need a way to...” and leaves the implementation open to discussion to all. This often leads to a programmer, who is more deeply concerned with how that function will operate on the data, coming up with a “how about a button that...” and/or just implementing the button as a suggestion. And then the UX architect and product lead, knowing that they don’t want to piss off this coder for fear of future pushback on their ideas, just caves and says “fine”. That’s the most common scenario I’ve seen at larger companies. That, and having woefully inexperienced UX and UI designers in the first place.
drewzero1 6y ago
The single most important lesson I learned in any of my software engineering courses was to listen first, build later. And keep asking questions until you understand the full requirements of the project! So much time and effort is wasted when programmers build first and ask questions later, and the whole process is needlessly frustrating for everyone involved. You're spot on re: humility and empathy. I see so much hubris in programmers/computer people thinking they/we can fully understand the world's problems, much less solve them.
deleted 6y ago
[deleted]
cactus2093 6y ago
This is a pretty lazy explanation of a problem, leaning on somewhat disparaging stereotypes like "nerds just want to nerd out" without even giving specific examples or looking at deeper reasons this might be happening. For starters, what context have you even experienced this in? From your description it sounds like both you and the programmer (or designer, as the case may be) are just doing this as a side project. Of course there's not going to be the incentive to follow-up and do the hard work of finding actual product-market fit if it was supposed to just be a fun learning experience from the beginning. Did you ever communicate with them what your expectations are, what the end goal is, how much of a time commitment you expect, and was the other person on the same page and equally invested in it? Also, why are you expecting the programmer to both figure out the nuances of the product and implement it? What is even your role in this, what do you bring to the table? It sounds to me like you did not communicate well or did not set expectations properly about this project, and now you're blaming the other person for doing a bad/lazy job.
phone8675309 6y ago
This is an excellent description of the CADT issue in most open source software.

pier25 6y ago

I've seen that too. UI designers not realizing UX is way more important than aesthetics.

jevgeni 6y ago
I think partly it is because UX is measurable (“A is less usable than B and thusly bad”), whereas aesthetics are not (“different tastes”). A kind of means to escape personal emotional accountability.
- TeMPOraL 6y ago
  The problem is also what we do with the ability to measure. Typically, we're making easy things intuitive, and difficult things impossible. This is exactly the wrong way to go about things, if you care about delivering value to users[0]. We should be making the easy things easy, hard things possible, and forget about the whole intuitiveness thing. There's this widespread belief now that software is only good if a user who never saw it before can become proficient in it in seconds to minutes. I think this is one of the most devastating, dangerous ideas in computing. The only way you can achieve a learning curve like this is by removing almost all functionality from software - make it so dumb that it really takes only a minute to figure it out entirely. Sadly, this is what we see in mobile and web applications these days. What worries me here is that we've conditioned everyone to assume software is immediately and fully discoverable. Nobody is expected to read the manual these days, and so manuals are not provided, and since manuals are not provided, any feature that cannot be made apparent without explaining it in the manual goes away. (Even with kitchen appliances, the situation isn't that bad. When a person sees a particular appliance for the first time, they do read the manual, or get someone to show them how to operate it. Maybe it comes with the fact that buying appliances is expensive and overall a hassle, whereas software is too easy to procure?) -- [0] - I highlight that condition, because it's my belief that most software vendors don't care about delivering value to users. They care about making money off users, and there are many cheaper ways to do that than creating a truly useful and ergonomic product.
  - jevgeni 6y ago
    This is a great insight, thank you! I *try* to make my software initially intuitive and gradually discoverable. I think a gentle learning curve is better than a completely flat one. I thought quite a bit recently about the problem that you are talking about (diminishing end user value in software). I think the source is that we have a lot of devs and designers whose only experience is designing for maximized conversion rate or maximized engagement. As opposed to professional software. They have no habit of designing for value. And *that’s the culture*. Go to any awwwards gallery - all of the websites or webapps mentioned there are essentially ads with minimal content. Which isn’t too bad, since it leaves a market untapped through the collective arrogance of the incumbents...
deleted 6y ago
[deleted]

phendrenad2 6y ago

This is exactly right. I also see this from programmer side-projects. The programmer finds a new cool idea, makes a MVP, then gets bored and moves on. Github is a holding yard for such things.

TheAceOfHearts 6y ago
Nothing wrong with writing simple side-projects and moving on, that's an excellent way to learn. Not everyone can afford to donate a bunch of their time in maintaining a project for free, especially considering it's often such a thankless task. The fact that the code is available means someone can fork it and make their own changes and improvements.
dgellow 6y ago
It’s not necessarily about getting bored. The research/experiment process can be the goal in itself. Not everything is about building a finite product.

msla 6y ago

This is the kind of thing project-based courses ought to train programmers to expect: Yeah, you're a legitimately good programmer, but programming mostly comes down to solving other peoples' problems, so you can't rest on your laurels. There's a whole, wide world out there of companies that need bespoke software, and most of the actual effort in writing that code is ensuring it properly enforces the business logic of a business you know nothing about. Therefore, in this project you'll be helping a professor from some non-CS department write educational software. You have to balance accessibility with pedagogical accuracy, as guided by someone who doesn't secretly know that some specific algorithm is the magic key to solving the problem.

chii 6y ago
There's a 2nd order problem, where the stake holder doesn't actually know the requirements until they see a sample implemented. "I'll know it when i see it" style. This is often the case, with bespoke software. If the stakeholder has such a clear vision of their end result, they probably won't need you to help them implement it!

systemvoltage 6y ago

I partially agree that designers love to create beautiful designs and they don't care about the products. This is giving a false complacency to what outta be a tight intergration between design + developers with an oversight from the product owner. It is simply inexcusable. We're actively creating a culture of disregard/complacency/ignorance by not shedding light on this as a huge problem in UX/UI design. I want more people to make noise about this.

LaundroMat 6y ago

Your comment makes me think of the distinction Simon Wardley[1] makes between Pioneers, Settlers and City Planners. The former are the ones who get excited by making something new (and not solving the problem), the latter are the ones who get excited by making sure things keep running flawlessly. I do believe there are programmers for every category though. [1] https://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...

microtherion 6y ago
Kirk McKusick had a similar metaphor around road building, with some people hacking a path through virgin jungle with a machete, some bulldozing the road, some paving it, some adding lamp posts, and some painting the lamp posts.

atoav 6y ago

As someone who both designs and programs for the better part of his life, nobody is really safe from that phenomena. If programming and designing is communication this is akin to go "let me say something", sprouting an interesting point, leaving the inplied punchline hanging and exiting the room while ignoring the reaction. If it happens once, okay — if it happens all the time, maybe you should do something about it. The thing is: both design and programming are more often than not messy when things get real, but every programmer wants to create clean and beautiful code and every designer wants to create aesthetical designs. Many intuitively perceive this "beauty" to be in tension with the complexity of the problem that needs solving. The goal of programming and design is however not to create beauty, but to solve problems and do so beautifully and clearly communicate these solutions, because it doesn't matter how beautiful your code/design is if nobody understands it. Beauty is the cherry on top that you get to achieve once the cake below is done, tastes well and puts a smile on the faces of all the party guests. If you are good you might already plan the cherry into the shape of the cake at the very beginning — but confusing the cherry for the cake IMO means you are either not there yet in terms of your profession or the thing is a toy project to try things out specifically — which is totally acceptable if everybody involved agrees and totally egoistic and shitty if they don't. Don't agree to serious projects you are not willing to commit to once the initial interest fades. Really good designers are about integrating both usabilty and aesthetics in an iterative process, and do so in such a way the problem is solved, and solved beautifully, all while reducing the cognitive overhead needed by users. And this cognitive overhead is really what should drive us. The work of programmers and designers is so beautiful/dangerous because it multiplies to a thousand people for a thousand hours. Our decision affect people on a daily basis. Removing a papercut might seem like nothing, but if it avoids irritating even ten other people who use that thing 10 times a day, isn't it the obvious thing to not half-ass on, not to toy around with? Btw. Design that is only about aesthetics is something that I call "styling" maybe we need a similar word for programmers who toy around?

TuringTest 6y ago
> If programming and designing is communication There's a research field called Semiotics of Human-Computer Interaction studying user interfaces from that angle. Developers usually have a technical background from maths or engineering, and often are not aware of the importance of linguistics in our field. Both programming languages and GUIs are languages (artificial, sure, but linguistics also study those) which are used to write expressions that can be read by humans. Semiotics, the study of signs and their meaning, provide methods to analyze how users make sense of the software artifacts (products and tools) delivered to them. One researcher called the user interface a designer's deputy, i.e. a messenger that conveys in its entirety a message that the programmers wants to communicate to the users. This deputy must stand on its own, since it's the only information available to the user. Users then perform sense-making on the symbols in the interface, to infer the meanings of all elements [1]. Notice that the user can't see what each interface element actually does, since they don't have access to the code; they can only guess what it does from the available symbols. If the symbols lead the user to infer an incorrect meaning, communication breaks. [1] https://blog.prototypr.io/how-semiotics-can-help-us-in-ux-on-deconstructing-experience-eaf3e55fb0e1 https://blog.prototypr.io/how-semiotics-can-help-us-in-ux-on...

dgellow 6y ago

I sympathize with what you’re saying, though I would like to point one thing regarding your first part: writing software is sometimes a way to wrap your mind around the problem and think about it. When trying to solve something new I like to start writing code early on because that gives me a canvas on which I can start drafting ideas. It’s more concrete than a whiteboard but can still be very abstract and flexible. That’s how I identify what I understand and what I don’t.

thom 6y ago

It’s always been notable to me that the thing that killed Flash wasn’t the wars with the usability community 20-odd years ago, it was the iPhone. People dumped these garish interfaces because a beautiful device came along that refused to run them, not because they were in many or perhaps most cases terrible for the task at hand. I think a lot of the methodological knowledge built by usability people has probably been ignored in favour of a metric-driven approach these days. That approach is very good at identifying bottlenecks in existing workflows or deciding between two ideas, but ultimately lacks the empathy you describe. You can only really build that by engaging directly with users, and watching them suffer at the hands of your creations.

matsemann 6y ago
I've always felt it a bit weird that iPhones quickly became the norm for all designers I've worked with, them hailing it as a so great to use. While I'm stuck not knowing how to find stuff, it's always hidden behind some undiscoverable swipe gesture. The home button used to have 10+ or so different functions based on context. They way you touched the screen (click, long press, 3d touch or whatnot) mattered. Do normal users know all this? Or do they just only use the 10% easy functionality of the phone and is happy with that? Maybe articles like "17 Things You Didn't Know Your iPhone's Home Button Could Do" is a sign usability has been sacrificed in order to have a clean&neat design.
- rkachowski 6y ago
  I have a half-baked still-gooey thought about this, but it's really around the time of the iphone (and the take off of the smartphone) that discoverability got thrown in the trash. Search bars instead of menus became the primary means of interaction, and ironically you can only find something with the search bar if you already know what you are looking for. Of course menus don't translate well to touch devices, and menu systems can quickly become unorganized junk drawers for functionality, but it feels like discoverability was never fully solved on touch devices.
  - bentcorner 6y ago

simonh 6y ago

This is why in so many problem domains, especially outside technical problems for IT people, proprietary software is the only option, or the only complete option. The best way to ensure people pay close attention to those last areas of fit and finish, and make sure they get attention from people with the different sets of skills needed to do a good job in all of those areas, is to pay them. That means you need a really solid revenue stream, and initially need enough capital up front to get the project going. I know, there are open source business models which work for some companies and that's true but generally in the sorts of technical problems for IT people. Compared to the IT industry as a whole those are edge cases. They seem more important to us embedded in the IT industry, but compared to the overall multi-trillion dollar global IT industry they're peanuts.

danjac 6y ago
> proprietary software is the only option, or the only complete option. If only that were true. I've watched a completely non-IT person work with both vanilla Gnome 3 and Windows 10; they found the former far more intuitive and unobtrusive (not looking at the individual apps, just the basic desktop UI). Proprietary design-by-committee doesn't necessary make for better solutions: hence the numerous complaints recently from people (often with accessibility issues) trying to book vaccination slots on government websites.
chaos_a 6y ago
This is why most linux distros have interfaces that are missing minor features and can be frustrating for users who don't have command line experience. For example, why can't I easily make a shortcut in ubuntu? Or how about the fact that you can't get full file paths shown in the default file manager, I often know what directory I want to get to but have to figure out what maze of folders I have to go through to get there.
- practice9 6y ago
  > Or how about the fact that you can't get full file paths shown in the default file manager, I often know what directory I want to get to but have to figure out what maze of files I have to go through to get there. Did you mean MacOS?

bottled_poe 6y ago

This is a great comment which concisely expresses my own thoughts on the topic. Junior developers could learn a lot by absorbing this insight.

harryf 6y ago

Also sometimes it’s the process a team working on a design follows. Tried to illustrate this long ago about mobile hamburger menus https://medium.com/@hfuecks/so-we-went-with-a-hamburger-menu-a69a2d24075b https://medium.com/@hfuecks/so-we-went-with-a-hamburger-menu...

koonsolo 6y ago

I think you're missing a few steps in your development process, or at least one. Normally it goes like this: problem->solution->implementation->testing. Each step has a role associated with this: user->analyst->coder->tester. If you go straight from problem to coder, you shouldn't be surprised that you don't have a proper solution, because nobody really made a proper solution. That's like building a house without an architect. Hire an analyst.

hulitu 6y ago
Testing is hard. That's why they let it to the user.
- _pmf_ 6y ago
  If I know that the user changes what he originally wanted, damn right I give the thing to the user instead of wasting effort on perfection and edge cases that get thrown out.
tonyedgecombe 6y ago
I don't know. The projects I got involved in that had an analyst involved tended to have reams of documentation for the obvious features, completely missed the non-obvious features and was wildly wrong in parts. This is what agile was created to solve. It was an acceptance of the reality and an attempt to live with that rather than trying to bend it to your will.
- koonsolo 6y ago
  Even agile teams need someone who analyses the solution. If there is nobody who specifies the solution, you get what OP describes. Agile does not exclude different roles, on the contrary.
411111111111111 6y ago
Most corporations aren't big enough to warrant dedicated personal for these roles. And if they are, it often ends with impossible to implement/maintain designs.

obscura 6y ago

This sounds like a flawed development cycle. Where's the end-user testing? In defence of the developers/programmers, many people are really bad at explaining what they want, not least because it's often not what they actually need. If a designer is designing something that looks good but doesn't work well (i.e., solve the problem), they are bad at usability/UX. They should be getting user feedback on their design before it's implemented - that's what user-centred design is about. There's often a gap when it comes to understanding requirements - between the end-user and the developer, between the designer and developer, etc. Requirements gathering is actually a specialised skill and one of the key duties of a business analyst.

myth2018 6y ago

I agree and I think your ideas form a good model to explain so many issues we've been facing more and more often. Some days ago I wrote here in HN about the change my stock broker made on their default home broker. It immediately becomes obvious that the people responsible for that design have never performed anything nontrivial with stocks. They created a symmetrical, colorful platform. The symmetry is enforced, therefore you don't have the flexibility of setting up your quote-boxes any longer (perhaps because that would break the artist's concept). Just to mention one of many issues the new design brought. The same applies to the Google Meet example in the article. Functionally, you'd never want those buttons presented that way. But placing them like that makes them look nice and symmetrical and Gestalt-related stuff, so that's the way to go and deal with it, dear users. > Perhaps the hardest part is having the humility to admit, "I don't understand the problem sufficiently" and the empathy to care about the problem enough to learn it well I agree, but don't see that happening, not in the short term at least. I had an argument with a designer some time ago about how much longer the project was going to take and how her ideas were actually substracting value from a user perspective. But she ended the discussion with a "this project has my signature, my reputation is in there". And that's what my criticism against current UX trends is all about. Artist's concept trumps user needs, project maintainability and everything. They are investing all the resources on graphic design matters and this is obstructing the whole field. Some UX folks argue that designers like those "aren't true UX designers". I agree, but those "false" designers seems to be outnumbering the "true" ones. The latter may eventually have to found a new discipline.

sriku 6y ago

There's a certain corollary effect to what you describe that perhaps applies to "modern" interfaces (both web and native desktop/mobile). Concurrency is excellent as an idea for systems design but horrible for user interfaces. Nothing seems to provide a stable interface and some concurrent process considers it it's privilege to suddenly modify a list of things I'm choosing from .. resulting in the items shifting just a few milliseconds before I click or tap my choice, which results in the wrong choice. This shift happens not only in vertical lists, but also tab-bar style buttons. To be precise concurrency isn't to blame for it, but it's more like laziness. The interface elements should be locked in place if the system detects that I'm about to select something. Whatever else is waiting to show up can wait, because I obviously didn't need to know about them a few milliseconds earlier.

KajMagnus 6y ago
> items shifting ... before I click ... results in the wrong choice Or a window from a different app pops up (the app took a while to start), steals the Enter key press, interprets Enter as "Yes do [something]", and then does it (but I didn't want that!). Why can't OS windows be click & mouse disabled for 2 seconds, after they open

nipponese 6y ago

Not sure why the designer always gets the blame here. The Product Manager set the requirements and sign off on the designs.

yen223 6y ago
One thing I learn from hacker news is that it's never the software engineer's fault
tomxor 6y ago
If the product manager dictates UI and UX design then they are the UI and UX designer and their title is meaningless. But what I think you really mean is that people are often in a blame culture that strategically puts up responsibility defenses which distracts them from producing a good result and focuses them on red taping to cover their asses. It is quite possible in these organizational structures to produce absolute shit and tick all the boxes and get everything approved and make sure no one in the position of actually doing stuff gets blamed for anything. Not saying that it's their personal fault that certain companies are that way, but it is possible to have some self respect and march back up to the manager and say hey this is shit and we should do a better design rather than waste time on this (ok, yes in a more articulate and respectful way) - if you think that risks your job then it's probably going to be more fruitful working somewhere else anyway. Disclaimer: yes I know real life has other restrictions that means not everyone can do this.

bsanr2 6y ago

I think it's simpler than that, in this case. What OP is describing is essentially a *control panel* (a small interface of grouped inputs for common tasks). This is an artifact of engineering design, where physical space and materials are usually at a premium, both in construction and usage. Once you've designed and built your controls, that's it; there's no spiriting a secondary interface out of thin air. However, with dynamic display-based interfaces, you can do just that. Much as I tend to loathe Apple's design, the way they handle iPad shutdowns is quite good: first, you press a button; then, the entire display changes to focus on this task. If you want to shutdown, you then have to perform an entirely different gesture to confirm. This layering of visual feedback and input types escapes the control panel paradigm and correctly takes advantage of the freedom that act lends to better communicate with the user. Unfortunately, doing so often means eschewing standards and best practices to find a solution that should work better for users. That is extremely difficult to get right; it's not very surprising that designers would purposely decide to use a flawed but known model instead. We need to get it out of our heads that designers only do things because they're visually satisfying. They are making purposeful and critical decisions to meet a design objective.

killtimeatwork 6y ago

> There are designers who love to create beautiful designs, and we love that, but beauty is the end of it for them. They don't actually care about the problem that the program (website, app, whatever) is supposed to solve. They're essentially aestheticians, not designers. Yep, I hate them too.

prox 6y ago

You literally described my job, I bridge the gap between design, code and make sure there is a thorough implementation of both, I have skills that overlap in those areas and so I can advise clients properly for any gaps that might have arisen. My bible is About Face : Interaction Design.

mst 6y ago
Speaking as a programmer who only occasionally interacts with design and considers himself largely terrible at it, reading "About Face" is probably the single book that helped the most to make me (slightly) less terrible.
- prox 6y ago
  It is always good to hear this! Especially the part about smart products and posture is very good to know by heart. So many apps still just botch their posture or completely forget the users intent and context (if they even consider it!)
  - mst 6y ago
    I'm afraid I probably still botch it. But About Face has at least helped me to try not to.
tootie 6y ago
Haha, yes! And that book is pretty ancient. I think the first edition dealt exclusively with building Windows desktop apps because the web wasn't ready yet. It lays out some of the blindingly obvious UX axioms that a lot of devs just don't bother to think about. One of them is "hide the ejection lever" (a metaphor for the ejection lever on a fighter jet) for exactly the kind of thing MJD is discussing. Have those irreversible, destructive controls be present and findable, but really hard to click by accident.
- prox 6y ago
  Haha, great example! It has had some revisions, my copy is from 2014, but the great thing is that it all remains relevant. The big takeaway is that humans shouldn’t be required to think like computers when they are interacting with one. “Warning : Failed to load library” <ok> Why did the library failed to load? Why are we being informed? Why does it say “Ok” when it is not ok? As a lovely example. And on the regular you still have these problems. The daily wtf is full of current day examples.

collyw 6y ago

I am beginning to think that hiring for enthusiastic programmers might be a mistake. Get on old cynical bastard like me. I just want to make my own life easy, and that means writing the easiest to maintain code that I can. Not trying out some new tech that has promised to solve all my problems.

danjac 6y ago

I think at one time there were a number of designers who transitioned from the print/magazine/brochure world to the web. They tended to prize "pixel perfection" and aesthetics over UX and functionality. This way of thinking is fine for making static landing and marketing pages, but is very counter-productive when you are building user-friendly, interactive and responsive applications. This is opposed to people who are actual UX experts who know how to trade off asethetics with usability.

austinjp 6y ago
There certainly were, I worked with a bunch of them. They were all talented, came from print and shifted to web + print. My job was to turn their gigantic Photoshop files into hand-crafted HTML, usually tables to layout carefully cropped and compressed JPEGs, and form elements :)
asoneth 6y ago
This mirrors my experience as a UX designer coming from the usability side. Many graphic design refugees are interested in learning about usability, user research, heuristics, Fitts' Law, GOMS/KLM, etc. But it takes time and energy. I've found that some small companies with no established UX team start out gravitating to shiny portfolio examples and end up putting visual design (VX) folks in charge of interaction design which sometimes goes poorly e.g. https://medium.com/intercom-inside/the-dribbblisation-of-design-406422ccb026 https://medium.com/intercom-inside/the-dribbblisation-of-des...
- danjac 6y ago
  "Too many designers are designing to impress their peers rather than address real business problems." This has its parallel with the developer world, where tech choices are made to impress the peer group (including those in other companies likely to be hiring you) rather than address the business problem at hand.

throwaway316943 6y ago

I think the problems with creating a working solution run both ways. I’ve been involved in many design sessions where the subject experts didn’t understand how to make their envisaged product useful to their audience. It’s a common problem in programming as well, you can write code that performs well and is correct but the interface is such a mess that it’s completely unusable by anyone else. If someone is designing for beauty alone they’re caught in the same trap, the composition will work well by itself but its purpose will be unintelligible. Producing a good design requires working with all parties involved including the end users.

Nasrudith 6y ago

Architects - of the original building sense have a similiar misplaced emphasis problem being more about appearances and "advancing the field (read: novelty)" than functionality. Brutalism was an infamous example for making downright needlessly depressing buildings to live and work in that don't even save on maintenance in spite of eschewing ornamentation. Other fun foibles include putting the duct work on the outside of the building, the mold trap that is Fallingwater, and accidentally having a skyscraper melt a very fancy car with its glare before they had to sandblast it away. It is kind of a tautology to say it but this hints at it being a human organizational social issue behind the pathology if it keeps cropping up. I agree that good design is hard and often involves substantial work beyond just making something on the sheet.

j-krieger 6y ago

You're describing me and my ''kind'' of programmers very well. I try to make myself interested in your problems. However, most of them seem really ''otherworldy'' to me or are in a domain I don't care about about. I became a programmer because I like the art of the trade, and I keep myself interested by writing interesting code.

daveswilson 6y ago

I like that theory. It may explain why the Google Workspace (/G Suite/Google Apps) icons are now so indistinguishable. If one looks nice, why not make the others look just as nice?

valeness 6y ago

I think it's important to note that product lead, system architect, and UX architect are distinct roles, each with distinct responsibilities, for a reason. It's not my job as a coder to care about your problem past what has been described to me. It is your job, as product lead, to care about the problem and design a sufficient information architecture, subdomain map, and other documentation to model your problem. This goes both ways. It is not your job to care about my problems past how it impacts the product. I don't expect you to know or care about how we design the software or how it is implemented; whether we use snake or camelCase, if we use openssl or pgp, if we choose mysql or postgresql. I just think it's important to outline that much of your comment can be applied in the inverse, and saying that "It's less work to become a mediocre programmer than to intimately understand the problem", is the same as saying "It's less work to become a mediocre product analyst than it is to intimately understand how to code". I agree with your last point, it's important for every department to have humility and empathy for the problems of their peers. But, it's not a problem to be figured out by designers and coders; it's instead an issue that extends further and requires effort from everyone involved, and at every level, to support.

creeble 6y ago
I agree here. I think a big part of the problem, even in big companies, is that those roles blur too much. In particular, it is frequently the case where a product lead says something like “we need a way to...” and leaves the implementation open to discussion to all. This often leads to a programmer, who is more deeply concerned with how that function will operate on the data, coming up with a “how about a button that...” and/or just implementing the button as a suggestion. And then the UX architect and product lead, knowing that they don’t want to piss off this coder for fear of future pushback on their ideas, just caves and says “fine”. That’s the most common scenario I’ve seen at larger companies. That, and having woefully inexperienced UX and UI designers in the first place.

drewzero1 6y ago

The single most important lesson I learned in any of my software engineering courses was to listen first, build later. And keep asking questions until you understand the full requirements of the project! So much time and effort is wasted when programmers build first and ask questions later, and the whole process is needlessly frustrating for everyone involved. You're spot on re: humility and empathy. I see so much hubris in programmers/computer people thinking they/we can fully understand the world's problems, much less solve them.

deleted 6y ago

[deleted]

cactus2093 6y ago

This is a pretty lazy explanation of a problem, leaning on somewhat disparaging stereotypes like "nerds just want to nerd out" without even giving specific examples or looking at deeper reasons this might be happening. For starters, what context have you even experienced this in? From your description it sounds like both you and the programmer (or designer, as the case may be) are just doing this as a side project. Of course there's not going to be the incentive to follow-up and do the hard work of finding actual product-market fit if it was supposed to just be a fun learning experience from the beginning. Did you ever communicate with them what your expectations are, what the end goal is, how much of a time commitment you expect, and was the other person on the same page and equally invested in it? Also, why are you expecting the programmer to both figure out the nuances of the product and implement it? What is even your role in this, what do you bring to the table? It sounds to me like you did not communicate well or did not set expectations properly about this project, and now you're blaming the other person for doing a bad/lazy job.

phone8675309 6y ago

This is an excellent description of the CADT issue in most open source software.