UX and UI, while related in some cases are two distinct things.
UX = User experience UI = User interface
In my opinion, UX should be used to drive the UI, backend & architecture.
UX, Then Architecture, Then Tools
21–30 of 41 posts
Re: UX, Then Architecture, Then Tools
#22> Virus Checker “I’ve been dying to write a new virus scanning algorithm, so I’m jumping right into that!” -> “Let’s design the UX” So, if I am a security researcher I should worry about UX before diving into attempting to characterize viruses? It appears that this article needs some explicit words on scoping. This is only relevant when strictly doing user application development.
[deleted]
Re: UX, Then Architecture, Then Tools
#23This is the right vision, but misses by a wide margin:
First, define the problem you are trying to solve. Then define the solution to that problem. Then lay out the broad strokes of the architecture and build a skeleton of a POC that proves the system will work.... and then figure out the UX and continue down the path from the article.
I've seen UX-first turn into churn of minutiae, without actually solving the business problems. Whole teams moving icons around for months and bikeshedding over whether they wanted 8 or 10 spaces between labels and fields, and still no functioning app.
UX-second - that works. Solve the problem first.
Re: UX, Then Architecture, Then Tools
#24> Virus Checker “I’ve been dying to write a new virus scanning algorithm, so I’m jumping right into that!” -> “Let’s design the UX” So, if I am a security researcher I should worry about UX before diving into attempting to characterize viruses? It appears that this article needs some explicit words on scoping. This is only relevant when strictly doing user application development.
I think most reading this would conclude the article is directed at developers building applications with some kind of user interaction...
Re: UX, Then Architecture, Then Tools
#25This is the right vision, but misses by a wide margin: First, define the problem you are trying to solve. Then define the solution to that problem. Then lay out the broad strokes of the architecture and build a skeleton of a POC that proves the system will work.... and then figure out the UX and continue down the path from the article. I've seen UX-first turn into churn of minutiae, without actually solving the busin…
> Whole teams moving icons around for months and bikeshedding over whether they wanted 8 or 10 spaces between labels and fields, and still no functioning app.
That sounds more like UI; I don't think this is what the author means by UX. Whether you have 8 or 10 spaces makes no impact on the architecture, but deciding that users should be able to change video quality does. If you try to decide on an architecture first, you will often constrain the UX of your product. If you don't realize that your product needs X feature, but your architecture doesn't support X, you're screwed.
Re: UX, Then Architecture, Then Tools
#26> Virus Checker “I’ve been dying to write a new virus scanning algorithm, so I’m jumping right into that!” -> “Let’s design the UX” So, if I am a security researcher I should worry about UX before diving into attempting to characterize viruses? It appears that this article needs some explicit words on scoping. This is only relevant when strictly doing user application development.
I disagree. Every product has a user, whether that product is in your web browser or a command line script. The way your user interacts with your product is its interface. I believe the author is suggesting that you must understand that interface first before you go off designing architecture.
If you are a security researcher designing a virus scanning algorithm, you need to understand how your users will interact with your scanner. Can they pause and resume? Can they tune the parameters of your scanner? Which parameters? etc. The way you answer these questions will invariably affect the architecture in some way.
Re: UX, Then Architecture, Then Tools
#27> Virus Checker “I’ve been dying to write a new virus scanning algorithm, so I’m jumping right into that!” -> “Let’s design the UX” So, if I am a security researcher I should worry about UX before diving into attempting to characterize viruses? It appears that this article needs some explicit words on scoping. This is only relevant when strictly doing user application development.
I disagree. Every product has a user, whether that product is in your web browser or a command line script. The way your user interacts with your product is its interface. I believe the author is suggesting that you must understand that interface first before you go off designing architecture. If you are a security researcher designing a virus scanning algorithm, you need to understand how your users will interact wi…
> Every product ...
Again, a very narrow characterization of when development happens.
Re: UX, Then Architecture, Then Tools
#28There really is no correct answer here. If you start with a database design, will you have a bad product? No answer can be given because there is so much other variables.
Re: UX, Then Architecture, Then Tools
#29Earlier quoted context omitted.
I disagree. Every product has a user, whether that product is in your web browser or a command line script. The way your user interacts with your product is its interface. I believe the author is suggesting that you must understand that interface first before you go off designing architecture. If you are a security researcher designing a virus scanning algorithm, you need to understand how your users will interact wi…
> Every product ... Again, a very narrow characterization of when development happens.
No, it's a narrow mentality of what a product is. If you are writing code, that code interacts with humans in some way. It might not be a consumer or even B2B product, it might be strictly an embedded library that interacts with nothing except other code, but even that should be designed to meet the needs of the other programmers who have to interact with it.
A lot of programmers want to be handed concrete requirements so they can focus solely on implementation, but in practice this leads to gaps. A programmer who thinks beyond their immediate scope to the end-to-end context and human players involved where their code is executed will deliver far more value and avoid so many common disasters that happen when non-technical people are solely responsible for requirements.
Re: UX, Then Architecture, Then Tools
#30I disagree with this. You have to explore the architecture first to see if the UX is technically possible. Once you know it’s possible, then you know the canvas you can paint on.