Webex Calling
Webex Calling
Webex Calling
Feature Design
Feature Design
Feature Design
To comply with NDA's and PIIAA's, I have omitted and redacted confidential information in my project showcase. All information in this case study is my own and does not necessarily reflect the views of Cisco
To comply with NDA's and PIIAA's, I have omitted and redacted confidential information in my project showcase. All information in this case study is my own and does not necessarily reflect the views of Cisco
To comply with NDA's and PIIAA's, I have omitted and redacted confidential information in my project showcase. All information in this case study is my own and does not necessarily reflect the views of Cisco
To comply with NDA's and PIAA's, I have omitted and redacted confidential information in my project showcase. All information in this case study is my own and does not necessarily reflect the views of Cisco
Sanitized Design
Example of a blank template (top) vs pre-configured (bottom)
Example of a blank template (top) vs pre-configured (bottom)
Example of a blank template (top) vs pre-configured (bottom)
Example of a blank template (top) vs pre-configured (bottom)
CONTEXT
CONTEXT
CONTEXT
CONTEXT
CONTEXT
Webex Calling is a complete enterprise-grade cloud calling and team collaboration solution offered by Cisco and managed through Control Hub — a platform which manages calling functions and calling capable devices in addition to other product services.
The project I worked on was how to better manage the buttons on a Webex Calling phone so that each button was configurable with a specific calling function. The current feature on Webex Calling could only be customized in a very archaic way and on separate applications. There was no easy way to bulk apply what each key and function should do across a group of users and devices, such as if the phones were being used by the marketing team. The interface was also not easily configurable by the final end-user.
This updated feature would be brought into Control Hub as part of Cisco’s overall strategy for managing everything within one platform, and to also update the current user experience.
Webex Calling is a complete enterprise-grade cloud calling and team collaboration solution offered by Cisco and managed through Control Hub — a platform which manages calling functions and calling capable devices in addition to other product services.
The project I worked on was how to better manage the buttons on a Webex Calling phone so that each button was configurable with a specific calling function. The current feature on Webex Calling could only be customized in a very archaic way and on separate applications. There was no easy way to bulk apply what each key and function should do across a group of users and devices, such as if the phones were being used by the marketing team. The interface was also not easily configurable by the final end-user.
This updated feature would be brought into Control Hub as part of Cisco’s overall strategy for managing everything within one platform, and to also update the current user experience.
Webex Calling is a complete enterprise-grade cloud calling and team collaboration solution offered by Cisco and managed through Control Hub — a platform which manages calling functions and calling capable devices in addition to other product services.
The project I worked on was how to better manage the buttons on a Webex Calling phone so that each button was configurable with a specific calling function. The current feature on Webex Calling could only be customized in a very archaic way and on separate applications. There was no easy way to bulk apply what each key and function should do across a group of users and devices, such as if the phones were being used by the marketing team. The interface was also not easily configurable by the final end-user.
This updated feature would be brought into Control Hub as part of Cisco’s overall strategy for managing everything within one platform, and to also update the current user experience.
Webex Calling is a complete enterprise-grade cloud calling and team collaboration solution offered by Cisco and managed through Control Hub — a platform which manages calling functions and calling capable devices in addition to other product services.
The project I worked on was how to better manage the buttons on a Webex Calling phone so that each button was configurable with a specific calling function. The current feature on Webex Calling could only be customized in a very archaic way and on separate applications. There was no easy way to bulk apply what each key and function should do across a group of users and devices, such as if the phones were being used by the marketing team. The interface was also not easily configurable by the final end-user.
This updated feature would be brought into Control Hub as part of Cisco’s overall strategy for managing everything within one platform, and to also update the current user experience.
Webex Calling is a complete enterprise-grade cloud calling and team collaboration solution offered by Cisco and managed through Control Hub — a platform which manages calling functions and calling capable devices in addition to other product services.
The project I worked on was how to better manage the buttons on a Webex Calling phone so that each button was configurable with a specific calling function. The current feature on Webex Calling could only be customized in a very archaic way and on separate applications.
There was no easy way to bulk apply what each key and function should do across a group of users and devices, such as if the phones were being used by the marketing team. The interface was also not easily configurable by the final end-user.
This updated feature would be brought into Control Hub as part of Cisco’s overall strategy for managing everything within one platform, and to also update the current user experience.
PROJECT ROLE
PROJECT ROLE
PROJECT ROLE
PROJECT ROLE
PROJECT ROLE
I was the feature designer assigned to this project and I worked closely with product managers, architecture as well as the front-end and back-end engineering team to update this feature. I also collaborated with designers working on other product specific areas to make sure the updates were all aligned and in sync.
I was the feature designer assigned to this project and I worked closely with product managers, architecture as well as the front-end and back-end engineering team to update this feature. I also collaborated with designers working on other product specific areas to make sure the updates were all aligned and in sync.
I was the feature designer assigned to this project and I worked closely with product managers, architecture as well as the front-end and back-end engineering team to update this feature. I also collaborated with designers working on other product specific areas to make sure the updates were all aligned and in sync.
I was the feature designer assigned to this project and I worked closely with product managers, architecture as well as the front-end and back-end engineering team to update this feature. I also collaborated with designers working on other product specific areas to make sure the updates were all aligned and in sync.
I was the feature designer assigned to this project and I worked closely with product managers, architecture as well as the front-end and back-end engineering team to update this feature. I also collaborated with designers working on other product specific areas to make sure the updates were all aligned and in sync.
CHALLENGES
CHALLENGES
CHALLENGES
CHALLENGES
CHALLENGES
I was newly transferred to the Webex Calling team when I started working on this feature, so I first had to learn what I was designing and understand what each button and function actually performed.
The other challenge was that different teams were in charge of different areas of Control Hub. Webex Calling and all its features such as — putting an active call on hold, conference calling, transfering calls, and voicemail, are all managed by the Webex Calling design team. However, the management of devices are managed by a separate team specializing in devices which include not only Webex Calling devices but also meeting room devices, headsets, and other peripherals.
This meant that any designs and updates made in Webex Calling would have to be aligned with a completely separate team with its own product roadmap and vision.
I was newly transferred to the Webex Calling team when I started working on this feature, so I first had to learn what I was designing and understand what each button and function actually performed.
The other challenge was that different teams were in charge of different areas of Control Hub. Webex Calling and all its features such as — putting an active call on hold, conference calling, transfering calls, and voicemail, are all managed by the Webex Calling design team. However, the management of devices are managed by a separate team specializing in devices which include not only Webex Calling devices but also meeting room devices, headsets, and other peripherals.
This meant that any designs and updates made in Webex Calling would have to be aligned with a completely separate team with its own product roadmap and vision.
I was newly transferred to the Webex Calling team when I started working on this feature, so I first had to learn what I was designing and understand what each button and function actually performed.
The other challenge was that different teams were in charge of different areas of Control Hub. Webex Calling and all its features such as — putting an active call on hold, conference calling, transfering calls, and voicemail, are all managed by the Webex Calling design team. However, the management of devices are managed by a separate team specializing in devices which include not only Webex Calling devices but also meeting room devices, headsets, and other peripherals.
This meant that any designs and updates made in Webex Calling would have to be aligned with a completely separate team with its own product roadmap and vision.
I was newly transferred to the Webex Calling team when I started working on this feature, so I first had to learn what I was designing and understand what each button and function actually performed.
The other challenge was that different teams were in charge of different areas of Control Hub. Webex Calling and all its features such as — putting an active call on hold, conference calling, transfering calls, and voicemail, are all managed by the Webex Calling design team. However, the management of devices are managed by a separate team specializing in devices which include not only Webex Calling devices but also meeting room devices, headsets, and other peripherals.
This meant that any designs and updates made in Webex Calling would have to be aligned with a completely separate team with its own product roadmap and vision.
I was newly transferred to the Webex Calling team when I started working on this feature, so I first had to learn what I was designing and understand what each button and function actually performed.
The other challenge was that different teams were in charge of different areas of Control Hub. Webex Calling and all its features such as — putting an active call on hold, conference calling, transfering calls, and voicemail, are all managed by the Webex Calling design team. However, the management of devices are managed by a separate team specializing in devices which include not only Webex Calling devices but also meeting room devices, headsets, and other peripherals.
This meant that any designs and updates made in Webex Calling would have to be aligned with a completely separate team with its own product roadmap and vision.
Screenshot and tutorial of how to edit the current feature, where you had to specify the function through special text
Screenshot and tutorial of how to edit the current feature, where you had to specify the function through special text
Screenshot and tutorial of how to edit the current feature, where you had to specify the function through special text
Screenshot and tutorial of how to edit the current feature, where you had to specify the function through special text
Screenshot and tutorial of how to edit the current feature, where you had to specify the function through special text
RESEARCH
RESEARCH
RESEARCH
RESEARCH
RESEARCH
I sought to understand all of the different functions that could be assigned to a button on the phone, also referred to as a Line-Key. I learned that Line-Keys could be designated as the following:
[Open] - The key is open for use.
[Primary Line] - The default line associated with the end-user and tied to the phone itself.
[Shared Line] - The same number can be shared with more than one person. This can appear on multiple devices and show when it is in use. Ex. call centers.
[Monitoring] - The specific status of someone else’s line can be seen from the Monitor List. This flashes green or red depending on the status.
Ex. Sales, reception, or some kind of support like IT. For example, if a salesperson is on a call that’s best answered by someone else, this allows them to easily check if the person is available for the call before transferring it.
[Speed Dial] - Set a specific number and label to dial to when pressed.
[Closed] - Button not in use.
I sought to understand all of the different functions that could be assigned to a button on the phone, also referred to as a Line-Key. I learned that Line-Keys could be designated as the following:
[Open] - The key is open for use.
[Primary Line] - The default line associated with the end-user and tied to the phone itself.
[Shared Line] - The same number can be shared with more than one person. This can appear on multiple devices and show when it is in use. Ex. call centers.
[Monitoring] - The specific status of someone else’s line can be seen from the Monitor List. This flashes green or red depending on the status.
Ex. Sales, reception, or some kind of support like IT. For example, if a salesperson is on a call that’s best answered by someone else, this allows them to easily check if the person is available for the call before transferring it.
[Speed Dial] - Set a specific number and label to dial to when pressed.
[Closed] - Button not in use.
I sought to understand all of the different functions that could be assigned to a button on the phone, also referred to as a Line-Key. I learned that Line-Keys could be designated as the following:
[Open] - The key is open for use.
[Primary Line] - The default line associated with the end-user and tied to the phone itself.
[Shared Line] - The same number can be shared with more than one person. This can appear on multiple devices and show when it is in use. Ex. call centers.
[Monitoring] - The specific status of someone else’s line can be seen from the Monitor List. This flashes green or red depending on the status.
Ex. Sales, reception, or some kind of support like IT. For example, if a salesperson is on a call that’s best answered by someone else, this allows them to easily check if the person is available for the call before transferring it.
[Speed Dial] - Set a specific number and label to dial to when pressed.
[Closed] - Button not in use.
I sought to understand all of the different functions that could be assigned to a button on the phone, also referred to as a Line-Key. I learned that Line-Keys could be designated as the following:
[Open] - The key is open for use.
[Primary Line] - The default line associated with the end-user and tied to the phone itself.
[Shared Line] - The same number can be shared with more than one person. This can appear on multiple devices and show when it is in use. Ex. call centers.
[Monitoring] - The specific status of someone else’s line can be seen from the Monitor List. This flashes green or red depending on the status.
Ex. Sales, reception, or some kind of support like IT. For example, if a salesperson is on a call that’s best answered by someone else, this allows them to easily check if the person is available for the call before transferring it.
[Speed Dial] - Set a specific number and label to dial to when pressed.
[Closed] - Button not in use.
I sought to understand all of the different functions that could be assigned to a button on the phone, also referred to as a Line-Key. I learned that Line-Keys could be designated as the following:
[Open] - The key is open for use.
[Primary Line] - The default line associated with the end-user and tied to the phone itself.
[Shared Line] - The same number can be shared with more than one person. This can appear on multiple devices and show when it is in use. Ex. call centers.
[Monitoring] - The specific status of someone else’s line can be seen from the Monitor List. This flashes green or red depending on the status.
Ex. Sales, reception, or some kind of support like IT. For example, if a salesperson is on a call that’s best answered by someone else, this allows them to easily check if the person is available for the call before transferring it.
[Speed Dial] - Set a specific number and label to dial to when pressed.
[Closed] - Button not in use.
Example of a Webex Calling Device with Line-Keys highlighted in red
Example of a Webex Calling Device with Line-Keys highlighted in red
Example of a Webex Calling Device with Line-Keys highlighted in red
Example of a Webex Calling Device with Line-Keys highlighted in red
Example of a Webex Calling Device with Line-Keys highlighted in red
VISUAL MAPPING
VISUAL MAPPING
VISUAL MAPPING
VISUAL MAPPING
VISUAL MAPPING
After understanding the features a bit more, mapping the buttons visually to the digital screen made for a better experience than having an ordered list. Since a calling device could have any number of buttons, from as little as four to up to ten depending on the model, the system would have to digitally represent the buttons on the screen based on the type of device chosen.
What this meant was if a phone had only four buttons, two on each side, the screen would represent it the same way with two rows and two columns. A phone with ten buttons would have five rows and two columns, corresponding to the physical layout of the device itself. This format would be clearer to the user as to which key was being customized.
After understanding the features a bit more, mapping the buttons visually to the digital screen made for a better experience than having an ordered list. Since a calling device could have any number of buttons, from as little as four to up to ten depending on the model, the system would have to digitally represent the buttons on the screen based on the type of device chosen.
What this meant was if a phone had only four buttons, two on each side, the screen would represent it the same way with two rows and two columns. A phone with ten buttons would have five rows and two columns, corresponding to the physical layout of the device itself. This format would be clearer to the user as to which key was being customized.
After understanding the features a bit more, mapping the buttons visually to the digital screen made for a better experience than having an ordered list. Since a calling device could have any number of buttons, from as little as four to up to ten depending on the model, the system would have to digitally represent the buttons on the screen based on the type of device chosen.
What this meant was if a phone had only four buttons, two on each side, the screen would represent it the same way with two rows and two columns. A phone with ten buttons would have five rows and two columns, corresponding to the physical layout of the device itself. This format would be clearer to the user as to which key was being customized.
After understanding the features a bit more, mapping the buttons visually to the digital screen made for a better experience than having an ordered list. Since a calling device could have any number of buttons, from as little as four to up to ten depending on the model, the system would have to digitally represent the buttons on the screen based on the type of device chosen.
What this meant was if a phone had only four buttons, two on each side, the screen would represent it the same way with two rows and two columns. A phone with ten buttons would have five rows and two columns, corresponding to the physical layout of the device itself. This format would be clearer to the user as to which key was being customized.
After understanding the features a bit more, mapping the buttons visually to the digital screen made for a better experience than having an ordered list. Since a calling device could have any number of buttons, from as little as four to up to ten depending on the model, the system would have to digitally represent the buttons on the screen based on the type of device chosen.
What this meant was if a phone had only four buttons, two on each side, the screen would represent it the same way with two rows and two columns. A phone with ten buttons would have five rows and two columns, corresponding to the physical layout of the device itself. This format would be clearer to the user as to which key was being customized.
Example of the visual mapping (exact layout and naming obscured for NDA reasons)
Example of the visual mapping (exact layout and naming obscured for NDA reasons)
Example of the visual mapping (exact layout and naming obscured for NDA reasons)
Example of the visual mapping (exact layout and naming obscured for NDA reasons)
Example of the visual mapping (exact layout and naming obscured for NDA reasons)
DESIGN COMPROMISES
DESIGN COMPROMISES
DESIGN COMPROMISES
DESIGN COMPROMISES
DESIGN COMPROMISES
As the designs for end-user customization continued, we encountered an unexpected challenge. This involved one of aforementioned line-key functions [Monitoring] —a button that would display a user's name and status based on a Monitoring List. The challenge was that the list was currently managed on a Calling product area, but the customization of a phone was managed through Devices.
Changing this list from the Devices page would take up unexpected engineering resources which were outside the scope of the feature since the architecture didn't currently support this. My team had to think through the implications behind this constraint and how this change would affect the interaction model. We explored two types of flows referred to as Reflow and Modify. Reflow is where the list cannot be changed, and Modify is where it could be changed when an end-user customizes their device.
As shown in the example below —with a Monitor List of Alice, Bob, Carol, Donna and 4 Line-Keys. What happens when you have to change the open second key and add a monitor button? What happens when you delete?
Reflow — Adding or Deleting a monitor button means that it automatically reflows the list to the pre-set Monitor List since it cannot be changed.
Modify — Changes the existing Monitor List, and Donna is added into the second button, and Carol deleted in the position you specified.
As the designs for end-user customization continued, we encountered an unexpected challenge. This involved one of aforementioned line-key functions [Monitoring] —a button that would display a user's name and status based on a Monitoring List. The challenge was that the list was currently managed on a Calling product area, but the customization of a phone was managed through Devices.
Changing this list from the Devices page would take up unexpected engineering resources which were outside the scope of the feature since the architecture didn't currently support this. My team had to think through the implications behind this constraint and how this change would affect the interaction model. We explored two types of flows referred to as Reflow and Modify. Reflow is where the list cannot be changed, and Modify is where it could be changed when an end-user customizes their device.
As shown in the example below —with a Monitor List of Alice, Bob, Carol, Donna and 4 Line-Keys. What happens when you have to change the open second key and add a monitor button? What happens when you delete?
Reflow — Adding or Deleting a monitor button means that it automatically reflows the list to the pre-set Monitor List since it cannot be changed.
Modify — Changes the existing Monitor List, and Donna is added into the second button, and Carol deleted in the position you specified.
As the designs for end-user customization continued, we encountered an unexpected challenge. This involved one of aforementioned line-key functions [Monitoring] —a button that would display a user's name and status based on a Monitoring List. The challenge was that the list was currently managed on a Calling product area, but the customization of a phone was managed through Devices.
Changing this list from the Devices page would take up unexpected engineering resources which were outside the scope of the feature since the architecture didn't currently support this. My team had to think through the implications behind this constraint and how this change would affect the interaction model. We explored two types of flows referred to as Reflow and Modify. Reflow is where the list cannot be changed, and Modify is where it could be changed when an end-user customizes their device.
As shown in the example below —with a Monitor List of Alice, Bob, Carol, Donna and 4 Line-Keys. What happens when you have to change the open second key and add a monitor button? What happens when you delete?
Reflow — Adding or Deleting a monitor button means that it automatically reflows the list to the pre-set Monitor List since it cannot be changed.
Modify — Changes the existing Monitor List, and Donna is added into the second button, and Carol deleted in the position you specified.
As the designs for end-user customization continued, we encountered an unexpected challenge. This involved one of aforementioned line-key functions [Monitoring] —a button that would display a user's name and status based on a Monitoring List. The challenge was that the list was currently managed on a Calling product area, but the customization of a phone was managed through Devices.
Changing this list from the Devices page would take up unexpected engineering resources which were outside the scope of the feature since the architecture didn't currently support this. My team had to think through the implications behind this constraint and how this change would affect the interaction model. We explored two types of flows referred to as Reflow and Modify. Reflow is where the list cannot be changed, and Modify is where it could be changed when an end-user customizes their device.
As shown in the example below —with a Monitor List of Alice, Bob, Carol, Donna and 4 Line-Keys. What happens when you have to change the open second key and add a monitor button? What happens when you delete?
Reflow — Adding or Deleting a monitor button means that it automatically reflows the list to the pre-set Monitor List since it cannot be changed.
Modify — Changes the existing Monitor List, and Donna is added into the second button, and Carol deleted in the position you specified.
As the designs for end-user customization continued, we encountered an unexpected challenge. This involved one of aforementioned line-key functions [Monitoring] —a button that would display a user's name and status based on a Monitoring List. The challenge was that the list was currently managed on a Calling product area, but the customization of a phone was managed through Devices.
Changing this list from the Devices page would take up unexpected engineering resources which were outside the scope of the feature since the architecture didn't currently support this. My team had to think through the implications behind this constraint and how this change would affect the interaction model.
We explored two types of flows referred to as Reflow and Modify. Reflow is where the list cannot be changed, and Modify is where it could be changed when an end-user customizes their device.
As shown in the example below —with a Monitor List of Alice, Bob, Carol, Donna and 4 Line-Keys. What happens when you have to change the open second key and add a monitor button? What happens when you delete?
Reflow — Adding or Deleting a monitor button means that it automatically reflows the list to the pre-set Monitor List since it cannot be changed.
Modify — Changes the existing Monitor List, and Donna is added into the second button, and Carol deleted in the position you specified.
Example of what will happen when you Add or Delete a Monitor Button
Example of what will happen when you Add or Delete a Monitor Button
Example of what will happen when you Add or Delete a Monitor Button
Example of what will happen when you Add or Delete a Monitor Button
Example of what will happen when you Add or Delete a Monitor Button
FINAL DESIGN
FINAL DESIGN
FINAL DESIGN
FINAL DESIGN
FINAL DESIGN
Asides from Add and Delete, we also considered what happens when the end-user had to Edit an existing Monitor button, or if the end-user wanted to swap the order of the line-keys. We re-explored the same interactions again depending on if the end-user had more keys than the amount of users currently on the Monitoring List, and vice versa (less keys than users on list).
After careful consideration with the team, we decided on the Reflow model for the first phase of the roadmap until we had the proper resources to support the Modify model. This decision was made recognizing that the Reflow model is currently less intuitive than the Modify model in the short-term.
The feature was supplemented with very strict copy and documentation by the content writing team to provide additional context and explanation. The feature also had links placed strategically and hierarchically to show where you could modify the Monitor List in when choosing to use this feature.
Asides from Add and Delete, we also considered what happens when the end-user had to Edit an existing Monitor button, or if the end-user wanted to swap the order of the line-keys. We re-explored the same interactions again depending on if the end-user had more keys than the amount of users currently on the Monitoring List, and vice versa (less keys than users on list).
After careful consideration with the team, we decided on the Reflow model for the first phase of the roadmap until we had the proper resources to support the Modify model. This decision was made recognizing that the Reflow model is currently less intuitive than the Modify model in the short-term.
The feature was supplemented with very strict copy and documentation by the content writing team to provide additional context and explanation. The feature also had links placed strategically and hierarchically to show where you could modify the Monitor List in when choosing to use this feature.
Asides from Add and Delete, we also considered what happens when the end-user had to Edit an existing Monitor button, or if the end-user wanted to swap the order of the line-keys. We re-explored the same interactions again depending on if the end-user had more keys than the amount of users currently on the Monitoring List, and vice versa (less keys than users on list).
After careful consideration with the team, we decided on the Reflow model for the first phase of the roadmap until we had the proper resources to support the Modify model. This decision was made recognizing that the Reflow model is currently less intuitive than the Modify model in the short-term.
The feature was supplemented with very strict copy and documentation by the content writing team to provide additional context and explanation. The feature also had links placed strategically and hierarchically to show where you could modify the Monitor List in when choosing to use this feature.
Asides from Add and Delete, we also considered what happens when the end-user had to Edit an existing Monitor button, or if the end-user wanted to swap the order of the line-keys. We re-explored the same interactions again depending on if the end-user had more keys than the amount of users currently on the Monitoring List, and vice versa (less keys than users on list).
After careful consideration with the team, we decided on the Reflow model for the first phase of the roadmap until we had the proper resources to support the Modify model. This decision was made recognizing that the Reflow model is currently less intuitive than the Modify model in the short-term.
The feature was supplemented with very strict copy and documentation by the content writing team to provide additional context and explanation. The feature also had links placed strategically and hierarchically to show where you could modify the Monitor List in when choosing to use this feature.
Asides from Add and Delete, we also considered what happens when the end-user had to Edit an existing Monitor button, or if the end-user wanted to swap the order of the line-keys. We re-explored the same interactions again depending on if the end-user had more keys than the amount of users currently on the Monitoring List, and vice versa (less keys than users on list).
After careful consideration with the team, we decided on the Reflow model for the first phase of the roadmap until we had the proper resources to support the Modify model. This decision was made recognizing that the Reflow model is currently less intuitive than the Modify model in the short-term.
The feature was supplemented with very strict copy and documentation by the content writing team to provide additional context and explanation. The feature also had links placed strategically and hierarchically to show where you could modify the Monitor List in when choosing to use this feature.
Sanitized Design
Example of a blank template (top) vs pre-configured (bottom)
Example of a blank template (top) vs pre-configured (bottom)
Example of a blank template (top) vs pre-configured (bottom)
Example of a blank template (top) vs pre-configured (bottom)
TAKEAWAYS
FINAL TAKEAWAYS
FINAL TAKEAWAYS
FINAL TAKEAWAYS
FINAL TAKEAWAYS
This project taught me that even if there is a perfect design that every stakeholder buys into, sometimes you still have to go with unavoidable compromises. What's important is to explore and exhaust all the possible options to see if there are other solutions, and if there aren't any, document what the ideal experience is so that it can get implemented in the future.
I learned that even if designers might be aligned with each other, other teams such as the architecture might not be. It's very important to expose designs earlier to faciliate conversations across teams, so that the best designs can be implemented and not be delayed or serve as roadblocks.
This project taught me that even if there is a perfect design that every stakeholder buys into, sometimes you still have to go with unavoidable compromises. What's important is to explore and exhaust all the possible options to see if there are other solutions, and if there aren't any, document what the ideal experience is so that it can get implemented in the future.
I learned that even if designers might be aligned with each other, other teams such as the architecture might not be. It's very important to expose designs earlier to faciliate conversations across teams, so that the best designs can be implemented and not be delayed or serve as roadblocks.
This project taught me that even if there is a perfect design that every stakeholder buys into, sometimes you still have to go with unavoidable compromises. What's important is to explore and exhaust all the possible options to see if there are other solutions, and if there aren't any, document what the ideal experience is so that it can get implemented in the future.
I learned that even if designers might be aligned with each other, other teams such as the architecture might not be. It's very important to expose designs earlier to faciliate conversations across teams, so that the best designs can be implemented and not be delayed or serve as roadblocks.
This project taught me that even if there is a perfect design that every stakeholder buys into, sometimes you still have to go with unavoidable compromises. What's important is to explore and exhaust all the possible options to see if there are other solutions, and if there aren't any, document what the ideal experience is so that it can get implemented in the future.
I learned that even if designers might be aligned with each other, other teams such as the architecture might not be. It's very important to expose designs earlier to faciliate conversations across teams, so that the best designs can be implemented and not be delayed or serve as roadblocks.
This project taught me that even if there is a perfect design that every stakeholder buys into, sometimes you still have to go with unavoidable compromises. What's important is to explore and exhaust all the possible options to see if there are other solutions, and if there aren't any, document what the ideal experience is so that it can get implemented in the future.
I learned that even if designers might be aligned with each other, other teams such as the architecture might not be. It's very important to expose designs earlier to faciliate conversations across teams, so that the best designs can be implemented and not be delayed or serve as roadblocks.