What should a UI designer know and how to deliver this knowledge to him?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite
1












I manage a few development teams at the moment. Each team develops different projects for different clients.



Right now I'm trying to let team leads work with clients directly without me, but the problem is that none of them has good experience designing UI. I do. We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she is neither into business nor into development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.



So, what do I do with designs? It consumes a significant portion of my time each week...



Let's summarize:



  1. The designer creates interfaces that are difficult to develop. Okay, I've handled to her my own sketch design system and introduced to main UI frameworks that we use. She is getting better at this.

  2. The designer isn't into business. She doesn't know when it makes sense to spend money on more complex things and when we should just make it simple and improve when needed. Okay, I may be able to put this responsibility on the Product Owner.

  3. The designer doesn't know all the intricacies of a product, PO's vision and user feedback. What do I do about it? If I'll ask her to consume all this information, then she'll be spending more time learning the product, than actually designing it.









share|improve this question









New contributor




stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.























    up vote
    1
    down vote

    favorite
    1












    I manage a few development teams at the moment. Each team develops different projects for different clients.



    Right now I'm trying to let team leads work with clients directly without me, but the problem is that none of them has good experience designing UI. I do. We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she is neither into business nor into development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.



    So, what do I do with designs? It consumes a significant portion of my time each week...



    Let's summarize:



    1. The designer creates interfaces that are difficult to develop. Okay, I've handled to her my own sketch design system and introduced to main UI frameworks that we use. She is getting better at this.

    2. The designer isn't into business. She doesn't know when it makes sense to spend money on more complex things and when we should just make it simple and improve when needed. Okay, I may be able to put this responsibility on the Product Owner.

    3. The designer doesn't know all the intricacies of a product, PO's vision and user feedback. What do I do about it? If I'll ask her to consume all this information, then she'll be spending more time learning the product, than actually designing it.









    share|improve this question









    New contributor




    stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















      up vote
      1
      down vote

      favorite
      1









      up vote
      1
      down vote

      favorite
      1






      1





      I manage a few development teams at the moment. Each team develops different projects for different clients.



      Right now I'm trying to let team leads work with clients directly without me, but the problem is that none of them has good experience designing UI. I do. We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she is neither into business nor into development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.



      So, what do I do with designs? It consumes a significant portion of my time each week...



      Let's summarize:



      1. The designer creates interfaces that are difficult to develop. Okay, I've handled to her my own sketch design system and introduced to main UI frameworks that we use. She is getting better at this.

      2. The designer isn't into business. She doesn't know when it makes sense to spend money on more complex things and when we should just make it simple and improve when needed. Okay, I may be able to put this responsibility on the Product Owner.

      3. The designer doesn't know all the intricacies of a product, PO's vision and user feedback. What do I do about it? If I'll ask her to consume all this information, then she'll be spending more time learning the product, than actually designing it.









      share|improve this question









      New contributor




      stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      I manage a few development teams at the moment. Each team develops different projects for different clients.



      Right now I'm trying to let team leads work with clients directly without me, but the problem is that none of them has good experience designing UI. I do. We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she is neither into business nor into development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.



      So, what do I do with designs? It consumes a significant portion of my time each week...



      Let's summarize:



      1. The designer creates interfaces that are difficult to develop. Okay, I've handled to her my own sketch design system and introduced to main UI frameworks that we use. She is getting better at this.

      2. The designer isn't into business. She doesn't know when it makes sense to spend money on more complex things and when we should just make it simple and improve when needed. Okay, I may be able to put this responsibility on the Product Owner.

      3. The designer doesn't know all the intricacies of a product, PO's vision and user feedback. What do I do about it? If I'll ask her to consume all this information, then she'll be spending more time learning the product, than actually designing it.






      team-management product-owner design






      share|improve this question









      New contributor




      stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 23 mins ago









      Glorfindel

      131119




      131119






      New contributor




      stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 7 hours ago









      stkvtflw

      1063




      1063




      New contributor




      stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      stkvtflw is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          2
          down vote













          To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to use your judgement on how quickly they can be self-sufficient or, better yet, discuss it with them and let them tell you.



          First, it is not ok for a designer to not understand how those designs are implemented in an application. Painters have to understand the intricacies of paint and canvas, the graphic designer has to understand how to design for applications. You mention PO, so I'm guessing your teams are practicing Scrum. If so, the designer is contributing to the product and is therefor a development team member. They should be in there each day making the product happen. There are many ways for people to share knowledge, but I've never seen one as good as pairing or group programming. This will not only let the designer feel when the designs are hard to implement, but will also help them learn the medium they are working in.



          Second, the team is solving a need for the business. No member of the Scrum team should be apathetic as to the needs of the business. They are only making an application to solve those needs. I don't know to what degree your team (including the designer) directly interact with the users and business, but I know when I was on a development team, having to own that solution when interacting with customers really changed my perspective and made me consider the business much more.



          With the designer, there's an extra thing that can really drive this home - rapid prototyping. In rapid prototyping (which can be as easy as building paper mock-ups), the team quickly puts designs in front of real users to start interacting with. This can let them get honest feedback before they get too attached to their chosen implementation.



          Thirdly, you may need to look at your own actions and try to see if you are accidentally introducing a crutch. When we make decisions or own a piece of the work for the team, they have a safety net. If they don't do it, they know you will. For this, I often point people to David Marquet's Ladder of Leadership. Working your way up this is a great way to shift ownership over to them and get those hours of your week back.






          share|improve this answer



























            up vote
            1
            down vote













            Analysis




            We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she isn't into business neither in development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.




            The problem here is actually quite simple: you are creating a single point of failure, and loading up a single person (your designer) with cross-domain responsibilities that properly belong to a team of people. This is exactly why agile frameworks like Scrum involve the entire team in planning and estimating work.



            What to Do Next



            Instead of expecting your designer to be an expert in UI design, engineering, and business, a more pragmatic approach is to ensure that designs are created collaboratively. Planning a new interface element should include:



            1. A Product Owner and/or business analyst to speak on behalf of the business functionality the design should address.

            2. A designer who can offer suggestions about ways to visually represent that functionality, or the various workflows around it.

            3. The engineering team, who can ask clarifying questions and ensure that ideas that are impractical or difficult to implement are redesigned or refined until they fit within the team's capabilities.

            In short, design should be a ping-pong exercise between the visual/workflow people and the engineers who are expected to do the actual implementation. Furthermore, the Product Owner must participate so that he or she can make sensible decisions about what features are most important to focus on, and which work items make the most economic sense to allocate resources towards.



            No matter how cross-functional your team members are—and it certainly sounds like they are not fully cross-functional—the entire team must work together to contribute their individual expertise towards building the product collaboratively. Treating design, engineering, and resource management as independent steps or activities is a recipe for failure.



            Rules of Engagement



            In order to collaborate, the entire team must contribute their collective knowledge and experience to each step in the development lifecycle. Most agile frameworks lay out some variation of the following rules of engagement to help with this:



            • The entire team takes part in the estimation or planning process.

            • Work is never generated somewhere upstream of the whole-team process, and then "tossed over the wall" to become someone else's problem to deliver.

            • Only the engineering team can estimate how much effort a proposed feature will require to product.

            • Only the Product Owner can prioritize the Product Backlog, and thereby control the amount of available project resources to allocate to a given feature.

            In short, stop treating UI design as an independent, upstream process. Treat UI design as a whole-team effort where there is ongoing collaboration rather than hand-offs.



            And finally, if you're the Product Owner, understand that while you can delegate role-related tasks, the responsibility and accountability of the Product Owner role still remains with you. Scrum is particularly adamant about the fact that the Product Owner is a unitary role, and while that role collaborates with the team it cannot distribute the Product Owner role across multiple people.



            Inspect and Adapt



            Even if you aren't following Scrum or some other agile framework, these rules of engagement address the pain points you're experiencing. If you choose not to follow these widely-accepted best practices, at least take the time to carefully inspect your current process, make changes to continuously improve that process, and be sure to measure your expected outcomes so that you can continue the inspect-and-adapt cycle until you achieve the results you want.



            An organizational culture of teamwork, and a process for continuous improvement, it is essential for solving most project-related problems. Put aside the inclination to "hold individuals accountable" and focus on systems-thinking to achieve the best results.






            share|improve this answer




















              Your Answer







              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "208"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              convertImagesToLinks: false,
              noModals: false,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              noCode: true, onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );






              stkvtflw is a new contributor. Be nice, and check out our Code of Conduct.









               

              draft saved


              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25061%2fwhat-should-a-ui-designer-know-and-how-to-deliver-this-knowledge-to-him%23new-answer', 'question_page');

              );

              Post as a guest






























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              2
              down vote













              To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to use your judgement on how quickly they can be self-sufficient or, better yet, discuss it with them and let them tell you.



              First, it is not ok for a designer to not understand how those designs are implemented in an application. Painters have to understand the intricacies of paint and canvas, the graphic designer has to understand how to design for applications. You mention PO, so I'm guessing your teams are practicing Scrum. If so, the designer is contributing to the product and is therefor a development team member. They should be in there each day making the product happen. There are many ways for people to share knowledge, but I've never seen one as good as pairing or group programming. This will not only let the designer feel when the designs are hard to implement, but will also help them learn the medium they are working in.



              Second, the team is solving a need for the business. No member of the Scrum team should be apathetic as to the needs of the business. They are only making an application to solve those needs. I don't know to what degree your team (including the designer) directly interact with the users and business, but I know when I was on a development team, having to own that solution when interacting with customers really changed my perspective and made me consider the business much more.



              With the designer, there's an extra thing that can really drive this home - rapid prototyping. In rapid prototyping (which can be as easy as building paper mock-ups), the team quickly puts designs in front of real users to start interacting with. This can let them get honest feedback before they get too attached to their chosen implementation.



              Thirdly, you may need to look at your own actions and try to see if you are accidentally introducing a crutch. When we make decisions or own a piece of the work for the team, they have a safety net. If they don't do it, they know you will. For this, I often point people to David Marquet's Ladder of Leadership. Working your way up this is a great way to shift ownership over to them and get those hours of your week back.






              share|improve this answer
























                up vote
                2
                down vote













                To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to use your judgement on how quickly they can be self-sufficient or, better yet, discuss it with them and let them tell you.



                First, it is not ok for a designer to not understand how those designs are implemented in an application. Painters have to understand the intricacies of paint and canvas, the graphic designer has to understand how to design for applications. You mention PO, so I'm guessing your teams are practicing Scrum. If so, the designer is contributing to the product and is therefor a development team member. They should be in there each day making the product happen. There are many ways for people to share knowledge, but I've never seen one as good as pairing or group programming. This will not only let the designer feel when the designs are hard to implement, but will also help them learn the medium they are working in.



                Second, the team is solving a need for the business. No member of the Scrum team should be apathetic as to the needs of the business. They are only making an application to solve those needs. I don't know to what degree your team (including the designer) directly interact with the users and business, but I know when I was on a development team, having to own that solution when interacting with customers really changed my perspective and made me consider the business much more.



                With the designer, there's an extra thing that can really drive this home - rapid prototyping. In rapid prototyping (which can be as easy as building paper mock-ups), the team quickly puts designs in front of real users to start interacting with. This can let them get honest feedback before they get too attached to their chosen implementation.



                Thirdly, you may need to look at your own actions and try to see if you are accidentally introducing a crutch. When we make decisions or own a piece of the work for the team, they have a safety net. If they don't do it, they know you will. For this, I often point people to David Marquet's Ladder of Leadership. Working your way up this is a great way to shift ownership over to them and get those hours of your week back.






                share|improve this answer






















                  up vote
                  2
                  down vote










                  up vote
                  2
                  down vote









                  To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to use your judgement on how quickly they can be self-sufficient or, better yet, discuss it with them and let them tell you.



                  First, it is not ok for a designer to not understand how those designs are implemented in an application. Painters have to understand the intricacies of paint and canvas, the graphic designer has to understand how to design for applications. You mention PO, so I'm guessing your teams are practicing Scrum. If so, the designer is contributing to the product and is therefor a development team member. They should be in there each day making the product happen. There are many ways for people to share knowledge, but I've never seen one as good as pairing or group programming. This will not only let the designer feel when the designs are hard to implement, but will also help them learn the medium they are working in.



                  Second, the team is solving a need for the business. No member of the Scrum team should be apathetic as to the needs of the business. They are only making an application to solve those needs. I don't know to what degree your team (including the designer) directly interact with the users and business, but I know when I was on a development team, having to own that solution when interacting with customers really changed my perspective and made me consider the business much more.



                  With the designer, there's an extra thing that can really drive this home - rapid prototyping. In rapid prototyping (which can be as easy as building paper mock-ups), the team quickly puts designs in front of real users to start interacting with. This can let them get honest feedback before they get too attached to their chosen implementation.



                  Thirdly, you may need to look at your own actions and try to see if you are accidentally introducing a crutch. When we make decisions or own a piece of the work for the team, they have a safety net. If they don't do it, they know you will. For this, I often point people to David Marquet's Ladder of Leadership. Working your way up this is a great way to shift ownership over to them and get those hours of your week back.






                  share|improve this answer












                  To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to use your judgement on how quickly they can be self-sufficient or, better yet, discuss it with them and let them tell you.



                  First, it is not ok for a designer to not understand how those designs are implemented in an application. Painters have to understand the intricacies of paint and canvas, the graphic designer has to understand how to design for applications. You mention PO, so I'm guessing your teams are practicing Scrum. If so, the designer is contributing to the product and is therefor a development team member. They should be in there each day making the product happen. There are many ways for people to share knowledge, but I've never seen one as good as pairing or group programming. This will not only let the designer feel when the designs are hard to implement, but will also help them learn the medium they are working in.



                  Second, the team is solving a need for the business. No member of the Scrum team should be apathetic as to the needs of the business. They are only making an application to solve those needs. I don't know to what degree your team (including the designer) directly interact with the users and business, but I know when I was on a development team, having to own that solution when interacting with customers really changed my perspective and made me consider the business much more.



                  With the designer, there's an extra thing that can really drive this home - rapid prototyping. In rapid prototyping (which can be as easy as building paper mock-ups), the team quickly puts designs in front of real users to start interacting with. This can let them get honest feedback before they get too attached to their chosen implementation.



                  Thirdly, you may need to look at your own actions and try to see if you are accidentally introducing a crutch. When we make decisions or own a piece of the work for the team, they have a safety net. If they don't do it, they know you will. For this, I often point people to David Marquet's Ladder of Leadership. Working your way up this is a great way to shift ownership over to them and get those hours of your week back.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 3 hours ago









                  Daniel

                  6,6202622




                  6,6202622




















                      up vote
                      1
                      down vote













                      Analysis




                      We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she isn't into business neither in development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.




                      The problem here is actually quite simple: you are creating a single point of failure, and loading up a single person (your designer) with cross-domain responsibilities that properly belong to a team of people. This is exactly why agile frameworks like Scrum involve the entire team in planning and estimating work.



                      What to Do Next



                      Instead of expecting your designer to be an expert in UI design, engineering, and business, a more pragmatic approach is to ensure that designs are created collaboratively. Planning a new interface element should include:



                      1. A Product Owner and/or business analyst to speak on behalf of the business functionality the design should address.

                      2. A designer who can offer suggestions about ways to visually represent that functionality, or the various workflows around it.

                      3. The engineering team, who can ask clarifying questions and ensure that ideas that are impractical or difficult to implement are redesigned or refined until they fit within the team's capabilities.

                      In short, design should be a ping-pong exercise between the visual/workflow people and the engineers who are expected to do the actual implementation. Furthermore, the Product Owner must participate so that he or she can make sensible decisions about what features are most important to focus on, and which work items make the most economic sense to allocate resources towards.



                      No matter how cross-functional your team members are—and it certainly sounds like they are not fully cross-functional—the entire team must work together to contribute their individual expertise towards building the product collaboratively. Treating design, engineering, and resource management as independent steps or activities is a recipe for failure.



                      Rules of Engagement



                      In order to collaborate, the entire team must contribute their collective knowledge and experience to each step in the development lifecycle. Most agile frameworks lay out some variation of the following rules of engagement to help with this:



                      • The entire team takes part in the estimation or planning process.

                      • Work is never generated somewhere upstream of the whole-team process, and then "tossed over the wall" to become someone else's problem to deliver.

                      • Only the engineering team can estimate how much effort a proposed feature will require to product.

                      • Only the Product Owner can prioritize the Product Backlog, and thereby control the amount of available project resources to allocate to a given feature.

                      In short, stop treating UI design as an independent, upstream process. Treat UI design as a whole-team effort where there is ongoing collaboration rather than hand-offs.



                      And finally, if you're the Product Owner, understand that while you can delegate role-related tasks, the responsibility and accountability of the Product Owner role still remains with you. Scrum is particularly adamant about the fact that the Product Owner is a unitary role, and while that role collaborates with the team it cannot distribute the Product Owner role across multiple people.



                      Inspect and Adapt



                      Even if you aren't following Scrum or some other agile framework, these rules of engagement address the pain points you're experiencing. If you choose not to follow these widely-accepted best practices, at least take the time to carefully inspect your current process, make changes to continuously improve that process, and be sure to measure your expected outcomes so that you can continue the inspect-and-adapt cycle until you achieve the results you want.



                      An organizational culture of teamwork, and a process for continuous improvement, it is essential for solving most project-related problems. Put aside the inclination to "hold individuals accountable" and focus on systems-thinking to achieve the best results.






                      share|improve this answer
























                        up vote
                        1
                        down vote













                        Analysis




                        We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she isn't into business neither in development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.




                        The problem here is actually quite simple: you are creating a single point of failure, and loading up a single person (your designer) with cross-domain responsibilities that properly belong to a team of people. This is exactly why agile frameworks like Scrum involve the entire team in planning and estimating work.



                        What to Do Next



                        Instead of expecting your designer to be an expert in UI design, engineering, and business, a more pragmatic approach is to ensure that designs are created collaboratively. Planning a new interface element should include:



                        1. A Product Owner and/or business analyst to speak on behalf of the business functionality the design should address.

                        2. A designer who can offer suggestions about ways to visually represent that functionality, or the various workflows around it.

                        3. The engineering team, who can ask clarifying questions and ensure that ideas that are impractical or difficult to implement are redesigned or refined until they fit within the team's capabilities.

                        In short, design should be a ping-pong exercise between the visual/workflow people and the engineers who are expected to do the actual implementation. Furthermore, the Product Owner must participate so that he or she can make sensible decisions about what features are most important to focus on, and which work items make the most economic sense to allocate resources towards.



                        No matter how cross-functional your team members are—and it certainly sounds like they are not fully cross-functional—the entire team must work together to contribute their individual expertise towards building the product collaboratively. Treating design, engineering, and resource management as independent steps or activities is a recipe for failure.



                        Rules of Engagement



                        In order to collaborate, the entire team must contribute their collective knowledge and experience to each step in the development lifecycle. Most agile frameworks lay out some variation of the following rules of engagement to help with this:



                        • The entire team takes part in the estimation or planning process.

                        • Work is never generated somewhere upstream of the whole-team process, and then "tossed over the wall" to become someone else's problem to deliver.

                        • Only the engineering team can estimate how much effort a proposed feature will require to product.

                        • Only the Product Owner can prioritize the Product Backlog, and thereby control the amount of available project resources to allocate to a given feature.

                        In short, stop treating UI design as an independent, upstream process. Treat UI design as a whole-team effort where there is ongoing collaboration rather than hand-offs.



                        And finally, if you're the Product Owner, understand that while you can delegate role-related tasks, the responsibility and accountability of the Product Owner role still remains with you. Scrum is particularly adamant about the fact that the Product Owner is a unitary role, and while that role collaborates with the team it cannot distribute the Product Owner role across multiple people.



                        Inspect and Adapt



                        Even if you aren't following Scrum or some other agile framework, these rules of engagement address the pain points you're experiencing. If you choose not to follow these widely-accepted best practices, at least take the time to carefully inspect your current process, make changes to continuously improve that process, and be sure to measure your expected outcomes so that you can continue the inspect-and-adapt cycle until you achieve the results you want.



                        An organizational culture of teamwork, and a process for continuous improvement, it is essential for solving most project-related problems. Put aside the inclination to "hold individuals accountable" and focus on systems-thinking to achieve the best results.






                        share|improve this answer






















                          up vote
                          1
                          down vote










                          up vote
                          1
                          down vote









                          Analysis




                          We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she isn't into business neither in development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.




                          The problem here is actually quite simple: you are creating a single point of failure, and loading up a single person (your designer) with cross-domain responsibilities that properly belong to a team of people. This is exactly why agile frameworks like Scrum involve the entire team in planning and estimating work.



                          What to Do Next



                          Instead of expecting your designer to be an expert in UI design, engineering, and business, a more pragmatic approach is to ensure that designs are created collaboratively. Planning a new interface element should include:



                          1. A Product Owner and/or business analyst to speak on behalf of the business functionality the design should address.

                          2. A designer who can offer suggestions about ways to visually represent that functionality, or the various workflows around it.

                          3. The engineering team, who can ask clarifying questions and ensure that ideas that are impractical or difficult to implement are redesigned or refined until they fit within the team's capabilities.

                          In short, design should be a ping-pong exercise between the visual/workflow people and the engineers who are expected to do the actual implementation. Furthermore, the Product Owner must participate so that he or she can make sensible decisions about what features are most important to focus on, and which work items make the most economic sense to allocate resources towards.



                          No matter how cross-functional your team members are—and it certainly sounds like they are not fully cross-functional—the entire team must work together to contribute their individual expertise towards building the product collaboratively. Treating design, engineering, and resource management as independent steps or activities is a recipe for failure.



                          Rules of Engagement



                          In order to collaborate, the entire team must contribute their collective knowledge and experience to each step in the development lifecycle. Most agile frameworks lay out some variation of the following rules of engagement to help with this:



                          • The entire team takes part in the estimation or planning process.

                          • Work is never generated somewhere upstream of the whole-team process, and then "tossed over the wall" to become someone else's problem to deliver.

                          • Only the engineering team can estimate how much effort a proposed feature will require to product.

                          • Only the Product Owner can prioritize the Product Backlog, and thereby control the amount of available project resources to allocate to a given feature.

                          In short, stop treating UI design as an independent, upstream process. Treat UI design as a whole-team effort where there is ongoing collaboration rather than hand-offs.



                          And finally, if you're the Product Owner, understand that while you can delegate role-related tasks, the responsibility and accountability of the Product Owner role still remains with you. Scrum is particularly adamant about the fact that the Product Owner is a unitary role, and while that role collaborates with the team it cannot distribute the Product Owner role across multiple people.



                          Inspect and Adapt



                          Even if you aren't following Scrum or some other agile framework, these rules of engagement address the pain points you're experiencing. If you choose not to follow these widely-accepted best practices, at least take the time to carefully inspect your current process, make changes to continuously improve that process, and be sure to measure your expected outcomes so that you can continue the inspect-and-adapt cycle until you achieve the results you want.



                          An organizational culture of teamwork, and a process for continuous improvement, it is essential for solving most project-related problems. Put aside the inclination to "hold individuals accountable" and focus on systems-thinking to achieve the best results.






                          share|improve this answer












                          Analysis




                          We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she isn't into business neither in development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.




                          The problem here is actually quite simple: you are creating a single point of failure, and loading up a single person (your designer) with cross-domain responsibilities that properly belong to a team of people. This is exactly why agile frameworks like Scrum involve the entire team in planning and estimating work.



                          What to Do Next



                          Instead of expecting your designer to be an expert in UI design, engineering, and business, a more pragmatic approach is to ensure that designs are created collaboratively. Planning a new interface element should include:



                          1. A Product Owner and/or business analyst to speak on behalf of the business functionality the design should address.

                          2. A designer who can offer suggestions about ways to visually represent that functionality, or the various workflows around it.

                          3. The engineering team, who can ask clarifying questions and ensure that ideas that are impractical or difficult to implement are redesigned or refined until they fit within the team's capabilities.

                          In short, design should be a ping-pong exercise between the visual/workflow people and the engineers who are expected to do the actual implementation. Furthermore, the Product Owner must participate so that he or she can make sensible decisions about what features are most important to focus on, and which work items make the most economic sense to allocate resources towards.



                          No matter how cross-functional your team members are—and it certainly sounds like they are not fully cross-functional—the entire team must work together to contribute their individual expertise towards building the product collaboratively. Treating design, engineering, and resource management as independent steps or activities is a recipe for failure.



                          Rules of Engagement



                          In order to collaborate, the entire team must contribute their collective knowledge and experience to each step in the development lifecycle. Most agile frameworks lay out some variation of the following rules of engagement to help with this:



                          • The entire team takes part in the estimation or planning process.

                          • Work is never generated somewhere upstream of the whole-team process, and then "tossed over the wall" to become someone else's problem to deliver.

                          • Only the engineering team can estimate how much effort a proposed feature will require to product.

                          • Only the Product Owner can prioritize the Product Backlog, and thereby control the amount of available project resources to allocate to a given feature.

                          In short, stop treating UI design as an independent, upstream process. Treat UI design as a whole-team effort where there is ongoing collaboration rather than hand-offs.



                          And finally, if you're the Product Owner, understand that while you can delegate role-related tasks, the responsibility and accountability of the Product Owner role still remains with you. Scrum is particularly adamant about the fact that the Product Owner is a unitary role, and while that role collaborates with the team it cannot distribute the Product Owner role across multiple people.



                          Inspect and Adapt



                          Even if you aren't following Scrum or some other agile framework, these rules of engagement address the pain points you're experiencing. If you choose not to follow these widely-accepted best practices, at least take the time to carefully inspect your current process, make changes to continuously improve that process, and be sure to measure your expected outcomes so that you can continue the inspect-and-adapt cycle until you achieve the results you want.



                          An organizational culture of teamwork, and a process for continuous improvement, it is essential for solving most project-related problems. Put aside the inclination to "hold individuals accountable" and focus on systems-thinking to achieve the best results.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered 54 mins ago









                          Todd A. Jacobs♦

                          30.7k329107




                          30.7k329107




















                              stkvtflw is a new contributor. Be nice, and check out our Code of Conduct.









                               

                              draft saved


                              draft discarded


















                              stkvtflw is a new contributor. Be nice, and check out our Code of Conduct.












                              stkvtflw is a new contributor. Be nice, and check out our Code of Conduct.











                              stkvtflw is a new contributor. Be nice, and check out our Code of Conduct.













                               


                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25061%2fwhat-should-a-ui-designer-know-and-how-to-deliver-this-knowledge-to-him%23new-answer', 'question_page');

                              );

                              Post as a guest













































































                              Comments

                              Popular posts from this blog

                              What does second last employer means? [closed]

                              Installing NextGIS Connect into QGIS 3?

                              One-line joke