Collaboration in design
Collaboration in design
December 21, 2023
As digital designers, we strive to create positive and meaningful interactions between humans and technology. We are advocating against dark patterns and marketing quirks. Instead, we are opting for building trust through good UX. We understand that building trust will, in turn, translate to better business outcomes.
We do this, by putting the user in the forefront of every design choice. We do this, with the use of empathy. Through user observations and interviews, we try to understand their feelings, goals, and frustrations.
I am truly passionate about this! My confusion begins when the empathy does not extend to the business owner, who is undertaking a career or financial risk to realize this product. Or to the developer, who is working tirelessly to bring the design to life in the most efficient and modern way possible.
Countless times, in my professional career, I experienced friction between designers and business representatives, or designers and programmers. We all have the same goal, turn the vision into a product. A product that needs to be usable, equitable, and desirable. But also, it must be built in time and budget, and it has to serve the business goals -if it is to survive-.
I recently came across the following:
The Design of Everyday Things, by Donald A. Norman. page 70, line 5 from the end
'But I predict, that even in the twenty-second century, there will still be forms that require precise accurate (but arbitrary) formats for no reason except the laziness of the programming team.'
It would be absurd for someone like me to criticize Norman, who has undoubtedly shaped the world of design, making extraordinary contributions both in academia and in business. He is making a point and a really important one! Machines should accommodate for human behavior, rather than humans accommodating for the precise and unnatural behavior of machines.
That quote just acted as a painful reminder of my own experiences and how I have struggled to satisfy everyone's expectations. Many times, I have sacrificed personal time, to improve the UI - because the deadline is approaching and there is no time for aesthetic changes or optimization-, to only be told off for not following the business priorities.
The mentioned quote is just a tangible example. One, I can use it to illustrate how different perspectives are considered when building a real-world product, resulting in decisions that may -on the surface- look like bad UX.
So, why can't we call the developers lazy (at least not yet, in this century )? Let's analyze what it would take:
To truly achieve a free-form input. One that translates human language and its true flexibility, we would have to use NLP (natural language processing, as a form of assistive AI). If not, we are just trying to capture all potential use cases, manually for every field, in every language. That is an extremely difficult and time-consuming task, which -at its best- will lead to: accounting for some, but not all use cases. The ultimate result? Unclear rules, more user frustration.
Now that you understand why we need NLP, let me explain why it may not be a great idea. Put simply, processing! To integrate AI into your software, you will need to account for the processing required to run it effectively. You have two options, it will either run in the front end or the back end. Neither is a great option (for the average business). If you run something on the client's browser (front end), you are limited to their specific machine's/browser specs. If you run it in the back end: every time you require NLP processing, you need to take the user's input from the front end and send it to the back end, where you can process it, get the result, and send it back to the front end. With the target feedback delay at 0.1s, this can be a challenge, depending on your company's tech stack.
But let's assume you are using modern technology (e.g. cloud processing functions), -potentially- you could achieve this. How long would it take to set up? How much research would be required to choose the most fitting NLP model or library? What about testing? Remember, software development is not just about taking requirements and coding them. It's about creating the underlying testing framework, setting up the infrastructure to support the development, and deploying each separate component while documenting everything.
For a moment, let's assume your developers take the time to set this up. What does this mean for the business? It means falling behind on other critical features. It means potentially missing the opportunity to hit the market before a competitor. It means a reduced budget because now we have to pay for the extra infrastructure and NLP support.
That's not all! AI is far from perfect! it will misread some of the user's inputs while attempting to translate them in an acceptable storing format. Now, think of a scenario, where the user typed an arbitrary date format and the system simply accepted it. In the user's mind, the correct date was input. In reality, the AI messed up the translation. A few weeks later, the user is trying to recover their account. One of the security questions is their date of birth. The user is typing the correct date but the system is refusing it.
Let's reflect on what would be the better user experience...Having to type a date in a specific format (or perhaps, visually selecting one, with a calendar widget), versus not being able to recover their account?
Yes, companies like Microsoft have solved this problem. But not upon their v1 launch. They first delivered, and then optimized. Why not follow the same paradigm?
No matter how well something is designed, a product that performs optimally, and is not error-prone, will result in a better UX. The developers are not lazy -for not including this feature-, they are been thoughtful and efficient.
Similarly, no matter how well something is designed, if it does not hit the market when the consumers need it, then it is not useful at all. The business stakeholder is not inconsiderate -for pushing timelines- , they are following their market research.
As designers, we can benefit from the views of other stakeholders and be more holistic and practical. Constraints should foster creativity, not create friction.
As digital designers, we strive to create positive and meaningful interactions between humans and technology. We are advocating against dark patterns and marketing quirks. Instead, we are opting for building trust through good UX. We understand that building trust will, in turn, translate to better business outcomes.
We do this, by putting the user in the forefront of every design choice. We do this, with the use of empathy. Through user observations and interviews, we try to understand their feelings, goals, and frustrations.
I am truly passionate about this! My confusion begins when the empathy does not extend to the business owner, who is undertaking a career or financial risk to realize this product. Or to the developer, who is working tirelessly to bring the design to life in the most efficient and modern way possible.
Countless times, in my professional career, I experienced friction between designers and business representatives, or designers and programmers. We all have the same goal, turn the vision into a product. A product that needs to be usable, equitable, and desirable. But also, it must be built in time and budget, and it has to serve the business goals -if it is to survive-.
I recently came across the following:
The Design of Everyday Things, by Donald A. Norman. page 70, line 5 from the end
'But I predict, that even in the twenty-second century, there will still be forms that require precise accurate (but arbitrary) formats for no reason except the laziness of the programming team.'
It would be absurd for someone like me to criticize Norman, who has undoubtedly shaped the world of design, making extraordinary contributions both in academia and in business. He is making a point and a really important one! Machines should accommodate for human behavior, rather than humans accommodating for the precise and unnatural behavior of machines.
That quote just acted as a painful reminder of my own experiences and how I have struggled to satisfy everyone's expectations. Many times, I have sacrificed personal time, to improve the UI - because the deadline is approaching and there is no time for aesthetic changes or optimization-, to only be told off for not following the business priorities.
The mentioned quote is just a tangible example. One, I can use it to illustrate how different perspectives are considered when building a real-world product, resulting in decisions that may -on the surface- look like bad UX.
So, why can't we call the developers lazy (at least not yet, in this century )? Let's analyze what it would take:
To truly achieve a free-form input. One that translates human language and its true flexibility, we would have to use NLP (natural language processing, as a form of assistive AI). If not, we are just trying to capture all potential use cases, manually for every field, in every language. That is an extremely difficult and time-consuming task, which -at its best- will lead to: accounting for some, but not all use cases. The ultimate result? Unclear rules, more user frustration.
Now that you understand why we need NLP, let me explain why it may not be a great idea. Put simply, processing! To integrate AI into your software, you will need to account for the processing required to run it effectively. You have two options, it will either run in the front end or the back end. Neither is a great option (for the average business). If you run something on the client's browser (front end), you are limited to their specific machine's/browser specs. If you run it in the back end: every time you require NLP processing, you need to take the user's input from the front end and send it to the back end, where you can process it, get the result, and send it back to the front end. With the target feedback delay at 0.1s, this can be a challenge, depending on your company's tech stack.
But let's assume you are using modern technology (e.g. cloud processing functions), -potentially- you could achieve this. How long would it take to set up? How much research would be required to choose the most fitting NLP model or library? What about testing? Remember, software development is not just about taking requirements and coding them. It's about creating the underlying testing framework, setting up the infrastructure to support the development, and deploying each separate component while documenting everything.
For a moment, let's assume your developers take the time to set this up. What does this mean for the business? It means falling behind on other critical features. It means potentially missing the opportunity to hit the market before a competitor. It means a reduced budget because now we have to pay for the extra infrastructure and NLP support.
That's not all! AI is far from perfect! it will misread some of the user's inputs while attempting to translate them in an acceptable storing format. Now, think of a scenario, where the user typed an arbitrary date format and the system simply accepted it. In the user's mind, the correct date was input. In reality, the AI messed up the translation. A few weeks later, the user is trying to recover their account. One of the security questions is their date of birth. The user is typing the correct date but the system is refusing it.
Let's reflect on what would be the better user experience...Having to type a date in a specific format (or perhaps, visually selecting one, with a calendar widget), versus not being able to recover their account?
Yes, companies like Microsoft have solved this problem. But not upon their v1 launch. They first delivered, and then optimized. Why not follow the same paradigm?
No matter how well something is designed, a product that performs optimally, and is not error-prone, will result in a better UX. The developers are not lazy -for not including this feature-, they are been thoughtful and efficient.
Similarly, no matter how well something is designed, if it does not hit the market when the consumers need it, then it is not useful at all. The business stakeholder is not inconsiderate -for pushing timelines- , they are following their market research.
As designers, we can benefit from the views of other stakeholders and be more holistic and practical. Constraints should foster creativity, not create friction.
As digital designers, we strive to create positive and meaningful interactions between humans and technology. We are advocating against dark patterns and marketing quirks. Instead, we are opting for building trust through good UX. We understand that building trust will, in turn, translate to better business outcomes.
We do this, by putting the user in the forefront of every design choice. We do this, with the use of empathy. Through user observations and interviews, we try to understand their feelings, goals, and frustrations.
I am truly passionate about this! My confusion begins when the empathy does not extend to the business owner, who is undertaking a career or financial risk to realize this product. Or to the developer, who is working tirelessly to bring the design to life in the most efficient and modern way possible.
Countless times, in my professional career, I experienced friction between designers and business representatives, or designers and programmers. We all have the same goal, turn the vision into a product. A product that needs to be usable, equitable, and desirable. But also, it must be built in time and budget, and it has to serve the business goals -if it is to survive-.
I recently came across the following:
The Design of Everyday Things, by Donald A. Norman. page 70, line 5 from the end
'But I predict, that even in the twenty-second century, there will still be forms that require precise accurate (but arbitrary) formats for no reason except the laziness of the programming team.'
It would be absurd for someone like me to criticize Norman, who has undoubtedly shaped the world of design, making extraordinary contributions both in academia and in business. He is making a point and a really important one! Machines should accommodate for human behavior, rather than humans accommodating for the precise and unnatural behavior of machines.
That quote just acted as a painful reminder of my own experiences and how I have struggled to satisfy everyone's expectations. Many times, I have sacrificed personal time, to improve the UI - because the deadline is approaching and there is no time for aesthetic changes or optimization-, to only be told off for not following the business priorities.
The mentioned quote is just a tangible example. One, I can use it to illustrate how different perspectives are considered when building a real-world product, resulting in decisions that may -on the surface- look like bad UX.
So, why can't we call the developers lazy (at least not yet, in this century )? Let's analyze what it would take:
To truly achieve a free-form input. One that translates human language and its true flexibility, we would have to use NLP (natural language processing, as a form of assistive AI). If not, we are just trying to capture all potential use cases, manually for every field, in every language. That is an extremely difficult and time-consuming task, which -at its best- will lead to: accounting for some, but not all use cases. The ultimate result? Unclear rules, more user frustration.
Now that you understand why we need NLP, let me explain why it may not be a great idea. Put simply, processing! To integrate AI into your software, you will need to account for the processing required to run it effectively. You have two options, it will either run in the front end or the back end. Neither is a great option (for the average business). If you run something on the client's browser (front end), you are limited to their specific machine's/browser specs. If you run it in the back end: every time you require NLP processing, you need to take the user's input from the front end and send it to the back end, where you can process it, get the result, and send it back to the front end. With the target feedback delay at 0.1s, this can be a challenge, depending on your company's tech stack.
But let's assume you are using modern technology (e.g. cloud processing functions), -potentially- you could achieve this. How long would it take to set up? How much research would be required to choose the most fitting NLP model or library? What about testing? Remember, software development is not just about taking requirements and coding them. It's about creating the underlying testing framework, setting up the infrastructure to support the development, and deploying each separate component while documenting everything.
For a moment, let's assume your developers take the time to set this up. What does this mean for the business? It means falling behind on other critical features. It means potentially missing the opportunity to hit the market before a competitor. It means a reduced budget because now we have to pay for the extra infrastructure and NLP support.
That's not all! AI is far from perfect! it will misread some of the user's inputs while attempting to translate them in an acceptable storing format. Now, think of a scenario, where the user typed an arbitrary date format and the system simply accepted it. In the user's mind, the correct date was input. In reality, the AI messed up the translation. A few weeks later, the user is trying to recover their account. One of the security questions is their date of birth. The user is typing the correct date but the system is refusing it.
Let's reflect on what would be the better user experience...Having to type a date in a specific format (or perhaps, visually selecting one, with a calendar widget), versus not being able to recover their account?
Yes, companies like Microsoft have solved this problem. But not upon their v1 launch. They first delivered, and then optimized. Why not follow the same paradigm?
No matter how well something is designed, a product that performs optimally, and is not error-prone, will result in a better UX. The developers are not lazy -for not including this feature-, they are been thoughtful and efficient.
Similarly, no matter how well something is designed, if it does not hit the market when the consumers need it, then it is not useful at all. The business stakeholder is not inconsiderate -for pushing timelines- , they are following their market research.
As designers, we can benefit from the views of other stakeholders and be more holistic and practical. Constraints should foster creativity, not create friction.