How does the choice of database transaction models: ACID (Atomicity, Consistency, Isolation, Duratbility) or BASE (Basic Availability, Soft State and Eventual Consistency) affect UX design?
Can someone share an example of how choosing one of these database models makes difference in user experience design?
As are all architectural decisions. This is why a software architect should be a part of the UXD process.
The choice of back-end architecture isn't something the UXD can decide, but user-facing factors can be evaluated from a UX perspective.
These database considerations will impact product experience:
^ All of those factors will impact the responsiveness of the interface and the trust established with the user.
software architect is not part of UXD process? What if UX Researcher has taken longer to define user-facing factors from UX perspective and Software Architect has moved on in the mean time?
Apr 16, 2016 at 6:37
This is an extension to Andrew Martin's answer, and the short comment discussion. I point to Andrew's answer as the short and simple correct answer:
Database construction and manipulation should never affect the UX design.
The rebuttal to Andrew's correct answer is one that we hear all too often:
ground realities are different. Database design and architecture is the first thing that is designed about an app rather than its UX.
But that database design should be part of the UX design. If the database was designed before user needs were defined, it was done too soon.
User Experience starts at inception of the product. While someone with "User Experience" in their title may not be sitting at the table the experience which will be presented to the user has already started. Knowing the need that the product is solving and how to present that solution is the start of forming your product's user experience.
The problem presented is that, a lot of the time, companies don't quite grasp this. They build an infrastructure around their needs instead of the user's needs. They then try to impose that structure on the user's work flow.
It is the people with "User Experience" in their job title that think of the user first, which is why those people should be part of the conversation from the beginning. Hopefully, people without "UX" in their job title are also thinking of the user.
To quite a piece of the rebuttal again:
Database design and architecture is the first thing that is designed...
That design is to the user's benefit. That design is defined by the process that started with user's needs at the core. How the user intends to interact with the system should guide how the database is designed and what transaction models should (or shouldn't be used).
To use an API analogy:
Is a RESTful API best, or does it make sense to use a SOAP API?
The two have very distinct advantages under certain situations. What type of API is chosen will absolutely affect the end point UX is several different ways. But the "UX Design" should have guided the decision process to picking which API is most appropriate.
Similarly, what database transaction models to use. What is the user actually doing, and what transaction model fits that best?
Here's the thing... a "UX Designer" is a loose term that hasn't been defined in context of this question. Let's, for the sake of argument, apply "UX Designer" to someone who is only working in the "Design" phase of the above image. Someone who "just draws pretty wireframes", so to speak.
It doesn't sound right to that "UX Designer" because that designer should be working under every proper assumption that what is designed on the backend was done with the user's best interest in mind. That designer should be confident that the "UX Researcher" was part of the initial process.
Going back to one of the initial points - even if someone with "UX" in their title was not part of each phase up until now: everything that has been done affects the user, making it all part of the UX design.
How does UX design affect the choice of transaction models ACID or BASE?
From a User Experience perspective, that is the right question to be asking. How does focusing on the user affect the system level choices being made.
It begins with developing the product strategy, followed by analyzing the user needs and their work flows, then defining the application's specifications. Now you have enough information to decide which transaction model is best.
Database construction and manipulation should never affect the UX design.
The design of the database should facilitate and optimise whatever processes the server-side operations require. As this takes place server-side it should have no impact on client-side and therefore no impact on UX design.
The only possible impact a database could have on UX is if it is returning wrong or incomplete data or if it is slow - Either way these are database design issues and not UX design issues.
should never affect the UX design My friend, ground realities are different. Database design and architecture is the first thing that is designed about an app rather than its UX. I know it may not sound right to a UX designer but it is a reality.
Apr 11, 2016 at 9:29
Delays are significant for UX.
Some solutions and patterns used in UI which work smoothly (feels instantaneous) with BASE to be problematic with ACID due intolerable response delays.
Delays are not the only significant thing for UX. User's trust in the system (say for something like an ERP) is quite significant. Could you please address that as well?
Apr 16, 2016 at 6:35