I'm primarily a native Apple application developer, but have done some backend stuff, as well. I have designed numerous Web sites, but I am not a particularly skilled Web designer.
I was, in the days of yore, an artist. I have also taken numerous design and usability courses, from the likes of NNG (Nielsen-Norman Group).
I'm a passable graphic designer, but don't pretend to be anywhere near "pro" level. I know enough to be dangerous (and use many of the tools).
I have designed a bunch of fancy widgets[0 - 4]. I actually use very few of them, because they are too intrusive.
I am in the "refining UX" stage of an iOS app that I've been developing for the last year and a half, or so. I'm working with designers and testers, to clean up the information architecture, interaction, usability, aesthetic design, and accessibility.
For me, the most valuable technique, has been rapid, high-quality prototyping. I have been abusing Apple's TestFlight[5] beta release system, and have been using it to make regular (usually, a couple a day) releases to the rest of the team, who are mostly non-tech people. I've made over 600 releases. The first release was made less than a month after first code submission.
The way I use it, is that I run what I call "constant beta." The app is always at "ship" Quality, even if incomplete. This means that the code people get, is fully operational, for the currently developed feature set, and they aren't using some kind of "lash-up" kludgy throwaway code. They are working with the actual code that will ship.
This has the advantage of constant vetting by Apple. They don't test TestFlight to the same level as the App Store, but they look for things like unsupported API usage, code signing issues, and obvious quality issues (like crashes). In at least one case, their testing found a crash that I missed.
Once the first release for a version has been vetted (takes a day or so), subsequent build releases, within that version, are approved almost immediately, so I get quick turnaround.
If the testers encounter crashes, I get a fairly useless report. If I use a Ouija board, I can often figure out the general part of the application affected.
With this workflow, we can have a highly iterative process, with aesthetics, usability, and general UX, being tested, almost from the start.
It also means that integration testing (the most important kind), starts almost immediately, and continues, throughout the development lifecycle.
It also means that I throw away a lot of good code. Most of those widgets I referenced were once in the app, and we decided not to use them, so I broke them into open-source packages, for reuse in future projects (I tend to eat my own dog food. I have a lot of packages in the app).
I'm pretty good at interpreting designs. I can accept Figma, Photoshop, Sketch, Illustrator, Napkin Sketch, or Hand-Wavy Verbal Description, and turn it into UX. I usually have something for the designers to try out, within minutes.
Most of the actual app assets are generated (and stored in the app) as vector PDF, via Illustrator, and I will often redesign raster art, into vector.
The designers and non-tech stakeholders seem to like it.
This is somewhat off-topic, but I'm worried about closed ecosystems, the shift towards censorship, and the end of private ownership. Good examples of this are walled gardens that break basic web links (Twitter for example), or DRM-encumbered digital books.
If I buy a physical book I can lend it to someone, or sell it if I want. If I buy a digital copy (which for some reason often costs more), not only can I not lend it but I can't sell it to anyone either. I also need to ask permission from the platform to read the book I rightfully purchased.
The Google/Apple app store duopoly is another example of this. Apple for example only allows you to use Safari, and makes it very hard for you to have any choice about what software you run on your own device.
It feels like there's a slow slide into a world where we no longer have any choice about what content we consume or how we consume it. Instead, we're spoonfed what the platform decides is good for us, and in most cases good means most profitable for the platform.
The problem is that your password reset token shouldn't be reusable. The token is only leaked after the person visited the reset page, which should invalidate the token on load.
Without a valid token, the reset form shouldn't load. Problem solved.
I'm primarily a native Apple application developer, but have done some backend stuff, as well. I have designed numerous Web sites, but I am not a particularly skilled Web designer.
I was, in the days of yore, an artist. I have also taken numerous design and usability courses, from the likes of NNG (Nielsen-Norman Group).
I'm a passable graphic designer, but don't pretend to be anywhere near "pro" level. I know enough to be dangerous (and use many of the tools).
I have designed a bunch of fancy widgets[0 - 4]. I actually use very few of them, because they are too intrusive.
I am in the "refining UX" stage of an iOS app that I've been developing for the last year and a half, or so. I'm working with designers and testers, to clean up the information architecture, interaction, usability, aesthetic design, and accessibility.
For me, the most valuable technique, has been rapid, high-quality prototyping. I have been abusing Apple's TestFlight[5] beta release system, and have been using it to make regular (usually, a couple a day) releases to the rest of the team, who are mostly non-tech people. I've made over 600 releases. The first release was made less than a month after first code submission.
The way I use it, is that I run what I call "constant beta." The app is always at "ship" Quality, even if incomplete. This means that the code people get, is fully operational, for the currently developed feature set, and they aren't using some kind of "lash-up" kludgy throwaway code. They are working with the actual code that will ship.
This has the advantage of constant vetting by Apple. They don't test TestFlight to the same level as the App Store, but they look for things like unsupported API usage, code signing issues, and obvious quality issues (like crashes). In at least one case, their testing found a crash that I missed.
Once the first release for a version has been vetted (takes a day or so), subsequent build releases, within that version, are approved almost immediately, so I get quick turnaround.
If the testers encounter crashes, I get a fairly useless report. If I use a Ouija board, I can often figure out the general part of the application affected.
With this workflow, we can have a highly iterative process, with aesthetics, usability, and general UX, being tested, almost from the start.
It also means that integration testing (the most important kind), starts almost immediately, and continues, throughout the development lifecycle.
It also means that I throw away a lot of good code. Most of those widgets I referenced were once in the app, and we decided not to use them, so I broke them into open-source packages, for reuse in future projects (I tend to eat my own dog food. I have a lot of packages in the app).
I'm pretty good at interpreting designs. I can accept Figma, Photoshop, Sketch, Illustrator, Napkin Sketch, or Hand-Wavy Verbal Description, and turn it into UX. I usually have something for the designers to try out, within minutes.
Most of the actual app assets are generated (and stored in the app) as vector PDF, via Illustrator, and I will often redesign raster art, into vector.
The designers and non-tech stakeholders seem to like it.
WFM. YMMV.
[0] https://github.com/RiftValleySoftware/RVS_Spinner
[1] https://github.com/RiftValleySoftware/RVS_MaskButton
[2] https://github.com/RiftValleySoftware/RVS_Checkbox
[3] https://github.com/RiftValleySoftware/RVS_RetroLEDDisplay
[4] https://github.com/RiftValleySoftware/RVS_AutofillTextField
[5] https://developer.apple.com/testflight/