UX, Then Architecture, Then Tools
morethancoding.com
UX, Then Architecture, Then Tools
1–10 of 41 posts
Re: UX, Then Architecture, Then Tools
#2I'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 the action failed or took longer than expected; refusing to be transparent and writing sentences like "We've received your order and will notify when ready" in the UI and working w/ push notifications.
For "UX first" to work, you actually need everybody w/ domain and technical knowledge involved, but that rarely happens.
> This Does Not Mean “Waterfall”
If you're not going back to adapt the UX to all requirements, it is. Any project that is phased like that instead of considering all requirements together is waterfall.
I recommend this book as a framework to run projects holistically, gathering requirements and executing against them in a way that finds the best fit:
https://www.goodreads.com/book/show/320553.Notes_on_the_Synt...
Re: UX, Then Architecture, Then Tools
#3I'd argue that UX and Architecture ought to be done in parallel with a decent amount of cross-feedback. I've seen this done with a big 1-2 day kick-off meeting with everything present at the start of the project. But I think the key thing is that design, development, and product don't work in isolation.
Re: UX, Then Architecture, Then Tools
#4I agree with this, but also I draw a different conclusion:
tools, tools, tools
I will implement the UX my smart colleagues from the Design Thinking group come up with. I bring the tools and the tech and the architecture to do that. Quickly. And if the UX changes after the first user test, my architecture, tools and modular code will easily accommodate the new UX.
At least that's the dream :D
Re: UX, Then Architecture, Then Tools
#5UX 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.
Re: UX, Then Architecture, Then Tools
#6I can say with more than a little bit of experience that the 'tools' never get written properly, as budget is is now blown, and the project timeframe is over-run.
Re: UX, Then Architecture, Then Tools
#7I'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 agree with just about everything you said here, (never read the book, so no opinion upon that). I would add that UX-first _can be_ the start of the conversation in a larger context.
Yes there are things that can't be done without a thorough review by an architect. But some things can be worked around without drastically affecting the UX, and that context can help an architect find places to hide the slow parts and inconsistencies.
I agree with the underlying drive of this article. The user experience is the most important part of what's being built. Where this article goes wrong is in assuming the UX is solely defined by the designers. The architecture is just as much ux as the visual / motion / interactive design.
The design isn't finished the day a system architect shows up to review it. It's just gotten started.
Re: UX, Then Architecture, Then Tools
#8I'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 addressing a well understood and pervasive problem, as opposed to a service or solution where you're trying to adapt to the varying needs of a broader market.
If you build like a house you might have plans that meet the needs of a few customers but you're going to have to re-design the house for the next set of customers. Software is generally more of a continuously developed service that needs to adapt as problems, jobs and markets change -- houses don't have to do this.
But I agree, "UX" first can work if it's iterated in small cycles continuously and the technical knowledge is involved in understanding the jobs and problems rather than the requirements and specifications.
Re: UX, Then Architecture, Then Tools
#9I'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 agree with just about everything you said here, (never read the book, so no opinion upon that). I would add that UX-first _can be_ the start of the conversation in a larger context. Yes there are things that can't be done without a thorough review by an architect. But some things can be worked around without drastically affecting the UX, and that context can help an architect find places to hide the slow parts and…
> I would add that UX-first _can be_ the start of the conversation in a larger context.
As a backend engineer who took a job where I also have to do frontend work, it took me a good six months to learn what you just summed up.
A good UX design really helps to highlight the context that the user is presented with, and it's much easier to iterate over and find gaps before having a hefty backend in place.
You can show a frontend design to your team, have them go over it and find edge cases you haven't considered, show it a manager to get early feedback, and then have confidence going into the backend work that you know the scope of what needs to be done.
Re: UX, Then Architecture, Then Tools
#10I'd argue that UX and Architecture ought to be done in parallel with a decent amount of cross-feedback. I've seen this done with a big 1-2 day kick-off meeting with everything present at the start of the project. But I think the key thing is that design, development, and product don't work in isolation.
I've had good experience doing UX first when your team is writing the whole stack. It's much easier to establish the scope of a project when you map out the user's context first; the whole team then has a good idea of what needs to be accomplished. If it's done in isolation though, there in lies the path to madness =)