7 ms·

This article is a good reminder. When I started out my programming career many years ago, these things were fundamental in the way I created software, however

This article is a good reminder. When I started out my programming career many years ago, these things were fundamental in the way I created software, however things seem to have gone downhill in recent years. The reason? The pressure in the past from co-founders or stakeholders to 'get things out the door quickly' and to get a quick and dirty MVP out there. This often meant lack of time to consider these small details (or even to backload them into the system later for v1.0). Also ironically, we've had professional UX and CX designers work on my software creations who have cut a lot of these things off the interface and functionality as 'unnecessary cruft'. I would also add to the list under Colours/Formatting, that a lot of 'dark mode' designs out there that are considered fashionable just have too low a colour contrast or too small a font to make it readable my someone like me with degrading eyesight.

nkrisc 7y ago
> Also ironically, we've had professional UX and CX designers work on my software creations who have cut a lot of these things off the interface and functionality as 'unnecessary cruft'. As a UX designer, that pains me. The only "unnecessary cruft" I've ever removed was stuff the CEO asked for but tested abysmally with users. We launched it, then quietly removed it a month or two later after they were able to show it off to whomever they were trying to impress.
- cyberferret 7y ago
  Sorry, I didn't mean it as a general swipe at all designers, and I am sure you are great at what you do. Specifically I am talking about the advice such as "Tell me what this does before I click on it" in the article. I tend to always put a description in small print under a button or option (or use a hover tooltip) to explain what a certain button will do when clicked (e.g. a button labelled "Assign Checklist", then underneath "Clicking this will assign a brand new checklist to the employee(s) you nominate". Or perhaps under an entry field for a mobile phone number, I specify in small print that the number should include the international dialling code etc.). These are examples of things that two different designers said to remove completely so the interface could be 'cool and clean' with minimal distractions. We did see an uptick in support queries about a few things after users inadvertently selected something at the wrong time or entered things incorrectly and wondered why they couldn't send text messages etc. On the flipside, there were a few screens with 4 or 5 lines of explanatory lines at the top or bottom that we removed and had nearly nil impact, or that users preferred. So I can see the necessity of lessening the things that users will read, but sometimes, I wish designers would go a little deeper and see when something that doesn't look as 'pretty' is still useful to keep.
  - lowercased 7y ago
    > I wish designers would go a little deeper and see when something that doesn't look as 'pretty' is still useful to keep. Won't happen until/unless dedicated design folks have to provide support for their creations. I don't particularly care what looks cool/clean/etc - after having done this for > 20 years, and constantly having to be the one who ends up fielding support issues - either directly from users, or via intermediate help desks - I generally have a pretty good idea of what will confuse or help many types of audiences. That's based on thousands of hours of dealing with common questions, weird hardware setups, language barriers, display issues, network speeds, etc. The design team doesn't play a role in supporting the product/service/users, but somehow manages to get ultimate authority on how everything should look. hrm....
    - rojcyk 7y ago
      I'll share the sentiment with @nkrisc. For a designer, this is really painful to read. But I do agree to some extent. Though it is a little bit more complicated than how you put it. > Won't happen until/unless dedicated design folks have to provide support for their creations. This is partially true. The way I work is that I always provide "the best" solution I can think of. I always explain the reasoning behind it. But then it all comes down to the client. You either have a solution that covers all edge cases, is extendable and works for the use case but usually isn't very cool. But the client "knows" that design sells. So they want something that "pops" and can serve as marketing material on its own. And at that moment it is about the pricing. If you charge hourly, you can iterate however long you want, you can have calls where you argue about usability and long term sustainability of your designs. But if you charge per project, at one point you will decide that you've done enough because it is no longer very cost-effective to continue like that. And you deliver what the client wants and what makes them happy. And this is where the whole conversation turns almost philosophical. Should you deliver something that is good for the product, but the client is not satisfied (and probably won't recommend you in the future)? Or do you make your client happy, but deliver a sub-par experience? (This happens less and less as I progress and charge more for my work, but still happens from time to time). You can argue that prioritizing product should deliver better long term results. But there are too many variables. There will be changes in the product that will make your solutions obsolete, or the implementation is not right and the promised result won't be delivered. Or the functionality of your designs change drastically, but the solution stays the same. So statistically, betting on a satisfied client is working better than on good product experience.
shantly 7y ago
My experience is a lot of money gets burnt making designs match some on-brand design that looks awesome in mockups but is worse for the user than just using the platform default GUI widgets with maybe some light color theming. Worse if they decide to customize widget behavior too (guaranteed to be worse than default—may look cool but there will be jank, broken state, and more) or do any special snowflake navigation crap when some normal and platform appropriate pattern would do. This adds cost and worsens UX. It has less to do with making the app look attractive from the user’s perspective than with designer ego and satisfying the brand-over-all-other-concerns product owner types. Usually there’s little discussion of features that will be missed so the widgets can work worse, but design flair should, properly, be part of the discussion of what your velocity may look like. [edit] I suspect some of the motivation for designers here is a combo of selling designs to clients or product owners, who are easily flattered that they need this kind of thing, and their version of résumé-driven-development—that is, highly-custom trendy screenshots probably “pop” a lot better in a portfolio than a better-functioning app that looks more ordinary.
- cyberferret 7y ago
  > that is, highly-custom trendy screenshots probably “pop” a lot better in a portfolio than a better-functioning app that looks more ordinary. I think you hit the nail on the head here. The designers that have worked on my site seem to be focused on screens that they can add to their Dribble portfolio rather than getting the job done in an efficient way for my users.
  - shantly 7y ago
    I know we’ve been busy declaring victory over all those old-timer print designers who’d transitioned to web & software, and hailing the rise of the “digital native” designer for like the whole past decade or so, but to me it looks like they’re all trying to make posters rather than software.
- rlpb 7y ago
  On the other hand, ignore the last fashions in UI design at your peril. Users will consider your website or app "dated" and adoption will suffer.
WalterBright 7y ago
> When I started out my programming career many years ago, these things were fundamental in the way I created software, however things seem to have gone downhill in recent years. I'm afraid there never was any golden age in software. > The pressure in the past from co-founders or stakeholders to 'get things out the door quickly' and to get a quick and dirty MVP out there. That's been true since Day 1 of software development. Certainly in all of my career.
- tstrimple 7y ago
  Sure, but those pressure vary quite wildly across industries and companies. I've had some roles where I felt I could actually treat this as a craft and feel proud of my results. There have been plenty of others where the drive to ship absolutely as soon as possible is the primary motivator. Usually in those instances it's where I've been brought into projects already running behind towards a due date and compromises had to be made. Those happen to be sequential for me, but I don't think it's a case of things actually being better in the good ol' days so much as that's when I had fewer other responsibilities and could spend much more of my time focused on the actual code rather than the dozens of other directions my attention is being demanded. I put out fires more than I create things at this point.
- lazyasciiart 7y ago
  There's no golden age in time, but for most people there is a golden age in their lifetime.

nkrisc 7y ago

> Also ironically, we've had professional UX and CX designers work on my software creations who have cut a lot of these things off the interface and functionality as 'unnecessary cruft'. As a UX designer, that pains me. The only "unnecessary cruft" I've ever removed was stuff the CEO asked for but tested abysmally with users. We launched it, then quietly removed it a month or two later after they were able to show it off to whomever they were trying to impress.

cyberferret 7y ago
Sorry, I didn't mean it as a general swipe at all designers, and I am sure you are great at what you do. Specifically I am talking about the advice such as "Tell me what this does before I click on it" in the article. I tend to always put a description in small print under a button or option (or use a hover tooltip) to explain what a certain button will do when clicked (e.g. a button labelled "Assign Checklist", then underneath "Clicking this will assign a brand new checklist to the employee(s) you nominate". Or perhaps under an entry field for a mobile phone number, I specify in small print that the number should include the international dialling code etc.). These are examples of things that two different designers said to remove completely so the interface could be 'cool and clean' with minimal distractions. We did see an uptick in support queries about a few things after users inadvertently selected something at the wrong time or entered things incorrectly and wondered why they couldn't send text messages etc. On the flipside, there were a few screens with 4 or 5 lines of explanatory lines at the top or bottom that we removed and had nearly nil impact, or that users preferred. So I can see the necessity of lessening the things that users will read, but sometimes, I wish designers would go a little deeper and see when something that doesn't look as 'pretty' is still useful to keep.
- lowercased 7y ago
  > I wish designers would go a little deeper and see when something that doesn't look as 'pretty' is still useful to keep. Won't happen until/unless dedicated design folks have to provide support for their creations. I don't particularly care what looks cool/clean/etc - after having done this for > 20 years, and constantly having to be the one who ends up fielding support issues - either directly from users, or via intermediate help desks - I generally have a pretty good idea of what will confuse or help many types of audiences. That's based on thousands of hours of dealing with common questions, weird hardware setups, language barriers, display issues, network speeds, etc. The design team doesn't play a role in supporting the product/service/users, but somehow manages to get ultimate authority on how everything should look. hrm....
  - rojcyk 7y ago
    I'll share the sentiment with @nkrisc. For a designer, this is really painful to read. But I do agree to some extent. Though it is a little bit more complicated than how you put it. > Won't happen until/unless dedicated design folks have to provide support for their creations. This is partially true. The way I work is that I always provide "the best" solution I can think of. I always explain the reasoning behind it. But then it all comes down to the client. You either have a solution that covers all edge cases, is extendable and works for the use case but usually isn't very cool. But the client "knows" that design sells. So they want something that "pops" and can serve as marketing material on its own. And at that moment it is about the pricing. If you charge hourly, you can iterate however long you want, you can have calls where you argue about usability and long term sustainability of your designs. But if you charge per project, at one point you will decide that you've done enough because it is no longer very cost-effective to continue like that. And you deliver what the client wants and what makes them happy. And this is where the whole conversation turns almost philosophical. Should you deliver something that is good for the product, but the client is not satisfied (and probably won't recommend you in the future)? Or do you make your client happy, but deliver a sub-par experience? (This happens less and less as I progress and charge more for my work, but still happens from time to time). You can argue that prioritizing product should deliver better long term results. But there are too many variables. There will be changes in the product that will make your solutions obsolete, or the implementation is not right and the promised result won't be delivered. Or the functionality of your designs change drastically, but the solution stays the same. So statistically, betting on a satisfied client is working better than on good product experience.

shantly 7y ago

My experience is a lot of money gets burnt making designs match some on-brand design that looks awesome in mockups but is worse for the user than just using the platform default GUI widgets with maybe some light color theming. Worse if they decide to customize widget behavior too (guaranteed to be worse than default—may look cool but there will be jank, broken state, and more) or do any special snowflake navigation crap when some normal and platform appropriate pattern would do. This adds cost and worsens UX. It has less to do with making the app look attractive from the user’s perspective than with designer ego and satisfying the brand-over-all-other-concerns product owner types. Usually there’s little discussion of features that will be missed so the widgets can work worse, but design flair should, properly, be part of the discussion of what your velocity may look like. [edit] I suspect some of the motivation for designers here is a combo of selling designs to clients or product owners, who are easily flattered that they need this kind of thing, and their version of résumé-driven-development—that is, highly-custom trendy screenshots probably “pop” a lot better in a portfolio than a better-functioning app that looks more ordinary.

cyberferret 7y ago
> that is, highly-custom trendy screenshots probably “pop” a lot better in a portfolio than a better-functioning app that looks more ordinary. I think you hit the nail on the head here. The designers that have worked on my site seem to be focused on screens that they can add to their Dribble portfolio rather than getting the job done in an efficient way for my users.
- shantly 7y ago
  I know we’ve been busy declaring victory over all those old-timer print designers who’d transitioned to web & software, and hailing the rise of the “digital native” designer for like the whole past decade or so, but to me it looks like they’re all trying to make posters rather than software.
rlpb 7y ago
On the other hand, ignore the last fashions in UI design at your peril. Users will consider your website or app "dated" and adoption will suffer.

WalterBright 7y ago

> When I started out my programming career many years ago, these things were fundamental in the way I created software, however things seem to have gone downhill in recent years. I'm afraid there never was any golden age in software. > The pressure in the past from co-founders or stakeholders to 'get things out the door quickly' and to get a quick and dirty MVP out there. That's been true since Day 1 of software development. Certainly in all of my career.

tstrimple 7y ago
Sure, but those pressure vary quite wildly across industries and companies. I've had some roles where I felt I could actually treat this as a craft and feel proud of my results. There have been plenty of others where the drive to ship absolutely as soon as possible is the primary motivator. Usually in those instances it's where I've been brought into projects already running behind towards a due date and compromises had to be made. Those happen to be sequential for me, but I don't think it's a case of things actually being better in the good ol' days so much as that's when I had fewer other responsibilities and could spend much more of my time focused on the actual code rather than the dozens of other directions my attention is being demanded. I put out fires more than I create things at this point.
lazyasciiart 7y ago
There's no golden age in time, but for most people there is a golden age in their lifetime.