Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UX, Then Architecture, Then Tools

morethancoding.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: UX, Then Architecture, Then Tools

#11

Post by vsareto »

Mertax wrote: post #8
hcarvalhoalves wrote: post #2

I've seen "UX first" gone terribly bad, because when designing the UX in a vacuum it's easy to glance over a lot of requirements imposed by the domain. E.g.: it's common for UX designers to expect any action in the app to be synchronous, which is often an impossibility (not just technical but from a business domain perspective), leading to UIs that pretend things already happened and puzzling users when it turns out…

I generally agree. This is why I think the home construction analogy for software might do more harm than it does good. If you go with the building construction analogy then the UX is just as much the architecture as it is the paint, floorings, materials etc. Even in the housing market, the same building plan does not work for your entire market. It depends on if you're developing software that is more of a tool addr…

Plus the purpose of a house generally does not change much. If you buy one, you're not going to turn it into a bar one year, then turn it into a candle shop the next. The requirements usually stay the same.

Some business apps do need to change every year. There's not any common sense for this situation (like house building) because you'd need to predict the future.

>UX first can work if it's iterated in small cycles continuously

Absolutely agreed, what I've generally seen is that the first iterations are there to get the UX grammar down with non-technical users. Then they can see what they like and don't like and their requirements become more coherent.

Re: UX, Then Architecture, Then Tools

#12

Post by suyash »

mkl95 wrote: post #5

UX first sounds great when you don't have to integrate your new application into a monolith where jQuery spaghetti and table-based HTML are spread like a disease.

good point, think the article failed to consider such use cases, most software is not written as brand new.

Re: UX, Then Architecture, Then Tools

#14

Post by j45 »

I’m a fan of user centric design, whether it’s domain driven design or a UX practice. I’m a Technology person too.

One thing that is dangerous about the above is from a top down perspective, UX folks don’t always know the possibilities and capabilities of tech (or feel they don’t need to) which can hinder the design.

As well, UX doesn’t always know how users prefer to work with the data for anything beyond mild and simple use cases. Results in a lack of depth, or too much depth.

It’s far more reasonable for creators (tech), designers and UX to be at the table from the start instead of any one group trying to abstract away the other in some sort of hierarchical or structural land grab.

If this doesn’t seem realistic, imagine if tech folks can learn to work with any type of detail easier than design folks can learn to code. The power will converge in developers who can design, and designers who can develop,

Re: UX, Then Architecture, Then Tools

#15

Post by lobsang »

I think some of the comments so far here and in the artice might be missing the point - not helped by the use of word UX or the common interpreation as meaning UI.

I think the author is advocating that you start with understanding the expectations of the product, what should the user be able to do, what do they need to do, what does the market expect. From that you then work out what tradeoffs need to be made in different areas and how to make them.

In that sense I completely agree - starting with anything else is just going to impose restrictions and limitations that are likely to go against what you want to acheive.

Re: UX, Then Architecture, Then Tools

#16

Post by hosh »

Or a more generalized take from Carol Sandford's regenerative business paradigm -- "external considering". It's not just UX. We can build UXs that are useful for the end user, or we can build UXs that sucks up attention for the benefit of monetization, producing significantly detrimental second-order effects to society. It's more than figuring out what the customer needs.

Each end user is a part of their own community, and they use these devices and apps as a service within their own community. There's a way to figure out how to help that end-user do that. It won't always even be a high tech solution all the time. It could be changes in operations, logistics, perhaps financing.

Instead of market lockin or monopoly power, what you get is non-displacability. That is, that end user and those communities those users are a part of don't want to get rid of your business, and your business forms a vital part of the health, well-being, and prosperity of that community.

Re: UX, Then Architecture, Then Tools

#18

Post by spandrew »

hcarvalhoalves wrote: post #2

I've seen "UX first" gone terribly bad, because when designing the UX in a vacuum it's easy to glance over a lot of requirements imposed by the domain. E.g.: it's common for UX designers to expect any action in the app to be synchronous, which is often an impossibility (not just technical but from a business domain perspective), leading to UIs that pretend things already happened and puzzling users when it turns out…

Isn't this what he's advocating for when he expresses the need to approach work "UX first" even when it comes to story and epic-level work?

Re: UX, Then Architecture, Then Tools

#19

Post by madsbuch »

> 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.

Re: UX, Then Architecture, Then Tools

#20

Post by dfrew »

lobsang wrote: post #15

I think some of the comments so far here and in the artice might be missing the point - not helped by the use of word UX or the common interpreation as meaning UI. I think the author is advocating that you start with understanding the expectations of the product, what should the user be able to do, what do they need to do, what does the market expect. From that you then work out what tradeoffs need to be made in diff…

This. A lot of people seem to be missing the forest for the trees. General point I took away was if you're starting on a new project and you're thinking about which tools (language, framework, db, etc) to use before you've taken time to understand the problem and articulate a solution (UX), you're not really setting yourself up for success. That seems pretty reasonable to me.
Post reply on HN