4 ms·

> So wouldn't it be ideal if designers or enterprise users could grapple with the nuances of the UI directly and implement it themselves? Oh, this always works

> So wouldn't it be ideal if designers or enterprise users could grapple with the nuances of the UI directly and implement it themselves? Oh, this always works! Why must we attempt to be so efficient? This curse of specialisation must be lifted, it has held us back for too long! /s obviously, but in seriousness: > [author] is a software engineer who has conducted over 1,400 technical interviews for ...etc etc I find it almost beyond belief that someone with a [supposedly] large amount of experience in software development would to think that allowing clients to implement UI themselves is a good idea.

diggan 6y ago
> I find it almost beyond belief that someone with a [supposedly] large amount of experience in software development would to think that allowing clients to implement UI themselves is a good idea. It's not at all strange as there are many different types of UIs that have to be built. I think what the author is thinking about is the typical CRUD applications that many businesses need and that are only built in-house, where the UI matters less than in consumer software, and the UX is still important but as long as it's changable, could be done by the users themselves. I feel like the UI you're thinking about is the one for consumer software, where you're innovating on some solution for a particular problem, and the UI/UX of the tool is probably the most important thing, otherwise people won't pick up the tool in the first place. If you look at the output of many software agencies, most of what they are producing is simple CRUD applications (and some startups do this too, I guess) which probably could be built by the users themselves, if it's basic enough. While the output of the ones building B2C software is slightly more complex and requires more thoughts behind it to even work out.
- lwhi 6y ago
  > .. where the UI matters less than in consumer software It's this statement that goes a long way to showing why we need UX professionals and UI designers. A good UI directly affects the bottom line of a company. A badly designed UI costs money. It's as simple as that.
  - diggan 6y ago
    Again, context and surrounding requirements are important to consider here. I'm not saying that it's always like that, or it's like that everywhere. But most internal CRUD apps could do with worse UI and still provide the same up front/bottom line value as some internal CRUD app with slightly better UI but requiring a developer to implement. Sometimes the cost for making the UI better costs more than the value you get from having that UI better. It's not a black-and-white "Better UI is always better", it simply depends on too many variables to have that frame of mind.
    - lwhi 6y ago
      Better usability is always better. The UI directly affects usability. If a problem is so straightforward it doesn't require designing, sure .. then go ahead and let anyone build it. If not, find someone who has spent time solving similar problems successfully.
      - diggan 6y ago
        > Better usability is always better Ok? The thing is, software is rarely created in a vacuum, if it was, we'd all be working towards perfection and never really reach it, nor complete or release any software. You have to balance constraints, and sometimes one of those constraints is money, or energy, or head count. Whatever. There is always balances to be made, and sometimes it's not worth to spend 20% of time increasing the usability by 2%. Sometimes it is, sometimes it's not. The apps I build for myself, that will never be published, has about 5% of my time thinking about the UI, because it simply doesn't matter and thinking more about it, won't make my life better in any way. Sometimes internal apps have to be treated the same way, if the constraints force you to treat them that way.
        lwhi 6y ago
        You were referring to applications that businesses use in-house. I responded to that point. I'm sorry, I still think my point stands. Even in-house software requires a good user experience, and the UI directly affects that UX. Designing a UI that works is a non trivial task; leaving it to people who don't have experience can effectively lead to a business losing a lot of money.
- vfc1 6y ago
  I think this is true, a lot of enterprise applications can be designed and are designed directly by the developers, that do a mix of backend and frontend work. By using a UI library like Angular Material, a UI framework like Material Design and some simple UI design principles, it's possible to build a more than decent UI experience, without having UI specialists on the team.
  - lwhi 6y ago
    The library doesn't solve any UX problems; it just means the components don't need to be built from scratch.
- RobertKerans 6y ago
  Nope, that is not what I'm thinking about. B2C applications have different constraints, sure, but that's not really anything to do with this. > If you look at the output of many software agencies, most of what they are producing is simple CRUD applications (and some startups do this too, I guess) which probably could be built by the users themselves, if it's basic enough. ...said every business manager ever. It's simple! Let the client configure it! [And normally] let's burn an absolute shit-ton of cash building unecessary things! I'm sorry to be dismissive here, but B2B UIs almost always have to reflect very specific business rules, they require careful turning for the clients. This doesn't mean they needs to be complicated, but they will have complexity. If a company allows their client to use a no code framework to build the UI of the product they are selling the client (I stress this is what is being suggested here, I am absolutely not saying that the UI itself cannot be built using prebuilt components), then there is another UI required to underly that, then an API/various APIs, etc, inception style. What the company has to build is a general framework to allow a client to use a framework to use the company's tool. By analogy, if a business is selling a tool, sometimes yes, it is correct to sell the parts of the tool instead for assembly by the client, but this adds an enormous amount of complexity to the product production and maintenance. More often selling the tool itself is the better option. Other commenters have noted how "no-code" tools will lead to productivity wins in some cases, as it's done for all similar tools in the past.
  - diggan 6y ago
    > said every business manager ever. It's simple! Let the client configure it! And apparently some developers as well, as I'm not a business manager :) > but B2B UIs almost always have to reflect very specific business rules I agree that some B2B UIs have to reflect specific business constraints, but there also others that don't, they just have to be a document storage. And others that don't even need that. And others that for sure have to have very specific constraints, maybe outside of the business or maybe not. I understand that you have a specific perspective on this, but I think your perspective is just considering one of many use cases of having an UI. There are others beyond that, especially when you talk about enterprise use cases, as many of those are hidden from the people not actively in enterprises, it's really hard to know as those details/workflows are often not public. But they are there, and anyone making assumptions about what others needs, are bound to be wrong at one point or another. I'm throwing my hands in the air and saying "probably some UIs could be done by the users themselves, if they have the tools" while also saying "there are UIs that needs professionals to be done correctly". Basically that the whole area is a large gray zone of "maybe this, maybe that", as there is no "almost always should be like this". The use cases are so many, and so different, that it's impossible for you to proclaim that someone is basically stupid for even thinking that users could implement their own UI.

diggan 6y ago

> I find it almost beyond belief that someone with a [supposedly] large amount of experience in software development would to think that allowing clients to implement UI themselves is a good idea. It's not at all strange as there are many different types of UIs that have to be built. I think what the author is thinking about is the typical CRUD applications that many businesses need and that are only built in-house, where the UI matters less than in consumer software, and the UX is still important but as long as it's changable, could be done by the users themselves. I feel like the UI you're thinking about is the one for consumer software, where you're innovating on some solution for a particular problem, and the UI/UX of the tool is probably the most important thing, otherwise people won't pick up the tool in the first place. If you look at the output of many software agencies, most of what they are producing is simple CRUD applications (and some startups do this too, I guess) which probably could be built by the users themselves, if it's basic enough. While the output of the ones building B2C software is slightly more complex and requires more thoughts behind it to even work out.

lwhi 6y ago
> .. where the UI matters less than in consumer software It's this statement that goes a long way to showing why we need UX professionals and UI designers. A good UI directly affects the bottom line of a company. A badly designed UI costs money. It's as simple as that.
- diggan 6y ago
  Again, context and surrounding requirements are important to consider here. I'm not saying that it's always like that, or it's like that everywhere. But most internal CRUD apps could do with worse UI and still provide the same up front/bottom line value as some internal CRUD app with slightly better UI but requiring a developer to implement. Sometimes the cost for making the UI better costs more than the value you get from having that UI better. It's not a black-and-white "Better UI is always better", it simply depends on too many variables to have that frame of mind.
  - lwhi 6y ago
    Better usability is always better. The UI directly affects usability. If a problem is so straightforward it doesn't require designing, sure .. then go ahead and let anyone build it. If not, find someone who has spent time solving similar problems successfully.
    - diggan 6y ago
      > Better usability is always better Ok? The thing is, software is rarely created in a vacuum, if it was, we'd all be working towards perfection and never really reach it, nor complete or release any software. You have to balance constraints, and sometimes one of those constraints is money, or energy, or head count. Whatever. There is always balances to be made, and sometimes it's not worth to spend 20% of time increasing the usability by 2%. Sometimes it is, sometimes it's not. The apps I build for myself, that will never be published, has about 5% of my time thinking about the UI, because it simply doesn't matter and thinking more about it, won't make my life better in any way. Sometimes internal apps have to be treated the same way, if the constraints force you to treat them that way.
      - lwhi 6y ago
        You were referring to applications that businesses use in-house. I responded to that point. I'm sorry, I still think my point stands. Even in-house software requires a good user experience, and the UI directly affects that UX. Designing a UI that works is a non trivial task; leaving it to people who don't have experience can effectively lead to a business losing a lot of money.
vfc1 6y ago
I think this is true, a lot of enterprise applications can be designed and are designed directly by the developers, that do a mix of backend and frontend work. By using a UI library like Angular Material, a UI framework like Material Design and some simple UI design principles, it's possible to build a more than decent UI experience, without having UI specialists on the team.
- lwhi 6y ago
  The library doesn't solve any UX problems; it just means the components don't need to be built from scratch.
RobertKerans 6y ago
Nope, that is not what I'm thinking about. B2C applications have different constraints, sure, but that's not really anything to do with this. > If you look at the output of many software agencies, most of what they are producing is simple CRUD applications (and some startups do this too, I guess) which probably could be built by the users themselves, if it's basic enough. ...said every business manager ever. It's simple! Let the client configure it! [And normally] let's burn an absolute shit-ton of cash building unecessary things! I'm sorry to be dismissive here, but B2B UIs almost always have to reflect very specific business rules, they require careful turning for the clients. This doesn't mean they needs to be complicated, but they will have complexity. If a company allows their client to use a no code framework to build the UI of the product they are selling the client (I stress this is what is being suggested here, I am absolutely not saying that the UI itself cannot be built using prebuilt components), then there is another UI required to underly that, then an API/various APIs, etc, inception style. What the company has to build is a general framework to allow a client to use a framework to use the company's tool. By analogy, if a business is selling a tool, sometimes yes, it is correct to sell the parts of the tool instead for assembly by the client, but this adds an enormous amount of complexity to the product production and maintenance. More often selling the tool itself is the better option. Other commenters have noted how "no-code" tools will lead to productivity wins in some cases, as it's done for all similar tools in the past.
- diggan 6y ago
  > said every business manager ever. It's simple! Let the client configure it! And apparently some developers as well, as I'm not a business manager :) > but B2B UIs almost always have to reflect very specific business rules I agree that some B2B UIs have to reflect specific business constraints, but there also others that don't, they just have to be a document storage. And others that don't even need that. And others that for sure have to have very specific constraints, maybe outside of the business or maybe not. I understand that you have a specific perspective on this, but I think your perspective is just considering one of many use cases of having an UI. There are others beyond that, especially when you talk about enterprise use cases, as many of those are hidden from the people not actively in enterprises, it's really hard to know as those details/workflows are often not public. But they are there, and anyone making assumptions about what others needs, are bound to be wrong at one point or another. I'm throwing my hands in the air and saying "probably some UIs could be done by the users themselves, if they have the tools" while also saying "there are UIs that needs professionals to be done correctly". Basically that the whole area is a large gray zone of "maybe this, maybe that", as there is no "almost always should be like this". The use cases are so many, and so different, that it's impossible for you to proclaim that someone is basically stupid for even thinking that users could implement their own UI.