Iyfjky

Question

We have had a self-proclaimed UX Expert foisted upon our development team recently and it's been nothing but headaches ever since. I am not sure what his background is but he does not know anything about HTML or CSS or browser compatibility, etc. There is no indication that he has ever worked in a development team environment and it has become painfully obvious that his design recommendations are based on his "artistic opinions" which really have no bearing on our application or what we need to accomplish. He doesn't conduct user interviews or testing nor does he do any kind of research from that angle (or any other angle). He does work with BA's and other SME's but he tends to talk at them without really paying attention to the big picture.

I understand there is a place for UX professionals out there, but we are not developing a commercial website or application, rather an internal back-office application that will be used by a limited number of people. The quick description is an application for checking account reconciliations and searching for documents and moving documents through workflows, etc. We need something that is fast and easy to use, it doesn't need to be flashy or entertaining, it needs to be solid and dependable and simple and intuitive. The end users will be trained on how to use the application, it's part of their job, and we don't need to dazzle them with intricate page controls or widgets and the simpler it is the better. That's not his mindset or approach at all.

Firing the guy is not an option, as he has connections much higher up the food chain. One thing we have tried is putting him with some junior level developers so that he feels like he is in charge of something but that has not worked out for a number of reasons, with a primary reason being that we need them for other tasks. The senior level developers have started ignoring him though because he doesn't understand or care about what they have tried to tell him about his recommendations. As the Team Lead I have expressed to him our concerns but it is not getting through - he thinks that since he is the UX Expert that whatever he recommends should be the final word.

We have tried following his recommendations to the letter in browser mock-ups to demonstrate the point we want to make. He gets frustrated and confused because it never seems to work like he expected it to... we didn't even want to take the time to do this but we thought it would help.

What should we do in this situation? Is there any way to break through? Due to resource constraints we are not in a position to offer any sort of training and I'm not sure that it would take anyway.

UPDATE:

So he interviewed for a Director level job. It was down to him and some lady from outside the company. He had the connections but she had the education. She is a PhD I think. It turns out this guy doesn't even have a bachelor's degree. Not that he would need it to do what he was doing before but this is a blue chip type company and typically to advance to a Director level position there are standards and requirements that have to be met. So she got the job and the kicker is, after he found out he resigned... someone else said they thought he had a lead at a different company. I don't know and I don't care, he's out of our misery now. :)

Are you forced to use his suggestions? If not, he's the one that needs to keep improving or suffer the fate of not using his work. Just make sure he's not taking up too much of your team's time. — user8365, Nov 15 '14 at 1:22
Update to the situation - so I found out at lunch yesterday that the guy in question is angling for a Director level job that has been open for a while... he has interviewed but another person is in the running... there will be a decision on it by the end of the month so they can fill the position before they close the books for EOY. Bottom line, I might only have a few more weeks to deal with this. Ah, I love good news to start the weekend! — Nov 15 '14 at 18:48

dennislees 51735 · Answer 1 · 2014-11-09 07:45:37Z

Acknowledge the problem, make him show his notes, force him to improve

[Edit: Worked in some good advice from the comments.]

The recommendation to post this over on workplace.se is not a bad one, but this political problem has such a strong UX leaning, it's unlikely that site will provide you with the specific advice you'll find most useful.

I think it's possible to make life easier with this guy, but not before stepping up, taking on the responsibility of Team Lead, and confronting the problem head on. This suggestion isn't going to make the problem disappear, just make it more livable-with, initially reduce his input by making more work for him, and eventually increasing the chances that his input provides actual value.

Engaging in some candid communication is often the best approach in these situations, but it's not an approach without risks. The main risk being that this guy turns out to be a real asshole, develops a nice big bruise on his ego, and decides to make things even worse out of spite.

I would call this guy aside and tell him that:

As the Team Lead, and being responsible of the ultimate state of the app, I have growing concerns about the nature of the UX input - specifically with the lack of transparency into the process, and the lack of rationale provided.

I was under the impression that UX recommendations were the result of research and evaluation (user research, heuristic evaluations, competitor benchmarking, usability testing, analytics datamining, etc.)

I was also under the impression that the point of all that work, and user-centricity in general, was to provide the context in which to make design decisions, and in what you've provided so far, it's not clear that this is what's actually happening.

When it comes to other aspects of the app, justifications have to be made, rationales provided. The sales guy requesting the feature needs to provide a business case, the engineer suggesting an architecture change needs to show a cost/benefits analysis of the approach, so it doesn't seem right that changes to the UI should come without any of this. Shouldn't it be the case that UX changes, because they potentially have the greatest influence on the end users, should be based on the greatest amount of research and rationale?

When you joined the team, I was excited at the prospect of learning about the app from the UX angle. (Be careful about feigning too much interest and excitement in his role. Work on the assumption that he has a finely tuned bullshit detector, and try not to trip it) I figured we'd be seeing some surveys/interviews and working sessions with users, the development of personas that we could use through out the development process to improve decision making, user journey maps to better visualize and communicate about the app, heuristic evaluations that might show up blind spots. I also figured that you'd be backing up your intuition and experience with data from analytics and testing, and that we might end up extending and improving our analysis based on your tests.

I didn't expect that we'd be making some of the changes you've been asking us to make without at least first testing some testing of hypotheses, or showing some proof of concept. Of course I understand that there needs to be some room for creativity, and you need flexibility when it comes to problem solving in UX, but I don't think that should be the primary driver behind change.

Essentially I hoped that with arrival of a UXer, we'd see the start of an 'environment of information' in which to work and make the app awesome. The reality is that this environment hasn't emerged, and a lot of the time it feels like we're implementing your subjective opinions, which just doesn't seem like the right way to be going about this.

So, (assuming he's not completely hostile towards your position at this stage) I'd like us to start working together on building that environment. I've mentioned the few examples that I know, but you're obviously going to have a better idea of best techniques and practices, so I think it'd make sense to start with an overall evaluation of the current approach, and then possibly turn that into a proposal to start filling in some of the blanks, with the end goal being a process where our changes and additions are based in solid data, and can be backed up.

Conclusion

Pulled off effectively, and assuming this guy is reasonable, this approach should initially get him out of your hair while he goes and spends lots of cycles strategizing about how he's going to change the world, and googling what 'heuristic evaluation' means ; )

If you can take control of the situation by showing him you have a firm grasp of what it is he should be providing, but giving him perceived freedom of going off and coming up with his own great ideas, but that are delivered on your terms i.e. with backup and rationale, you turn the tables on him. You essentially reframe the relationship.

Again, it's a risky approach, and if you don't have a great deal of confidence that you can pull it off, you should ask for general advice on how to handle this sort of situation, either from your HR dept, or somewhere like work workplace.se A couple of good books that deal with the topic are Difficult Conversations: How to Discuss What Matters Most and Crucial Conversations: Tools for Talking When the Stakes Are High

The ultimate goal is that this guy will actually learn how complex and diverse a discipline UX really is and get somewhat of a reality check, hopefully leading to a widening of his vision of his role, and eventually to an improvement in the quality of his input.

All of which should make your app better, and make life a bit easier for you and the rest of your team : )

+1, but one tweak: Saying "When you joined the team, I was excited at the prospect of learning about the app from the UX angle." when in fact the UX guy was "foisted upon" the team lead isn't honest, and his BS detector may well go off. Sticking to honesty -- but constructively as with all your other points -- is the way to go. — Nov 9 '14 at 11:14
Just a quick note: neither User Experience nor The Workplace is a "board". These are not fora. — Nov 9 '14 at 13:04
This is all good advice. I would add that its necessary to start off the conversation by listening. Don't view the conversation as a way to explain your points to him, but as a chance for you each to learn more about the other person's viewpoint. If you first take the time to learn his side of the issue, you'll find him much more receptive to listening to your own view. You may even find that he would like to be doing user research but is blocked by some impediment that you can help to remove. — Nov 9 '14 at 17:55
If you don't have experience in this type of negotiation, I recommend reading Difficult Conversations: How to Discuss What Matters Most ahead of time. — Nov 9 '14 at 17:56
@3nafish Yup, good tip. Another option, and the book I refer back to most on the this topic, is Crucial Conversations — dennislees, Nov 9 '14 at 18:21

NotMe 20.9k55695 · Answer 2 · 2014-11-10 15:23:26Z

Without seeing his work, I can't comment on whether his input is useful or not. However, I can point out what a UX expert doesn't need to know: the implementation details. In other words, they don't need to be able to put HTML or CSS together.

However, they do need to know how screen layout, including things like color and font choice, can impact usability. These items might appear to be "artistic options" to you, but can have an impact on a persons ability to quickly perceive what they need to do on the page. Even just a line in the right place can help break areas of the screen up into something much more readable.

How I would approach the situation: Have him create a mockup. He should be able to do this with just pencil and paper. Bonus points if he can use something like Photoshop to put the right colors/fonts in, but that's not necessary. Once done, he should present this to the group and be able to walk through the process flow. Your job then would be to point out any missing features like "how do you delete a document?" Do so in a professional way without attacking him. Make sure he has the full expected feature list prior to drawing the mockup.

Once you have an acceptable mockup, have one of your devs through together a few screens that have the look. Then step through that, making some minor tweaks. This should result in a decent screen layout your team can throw the code behind. Execute on it, even if you think that picture in the top left corner isn't necessary. Management will judge him on it later and you'll have the documentation showing how you followed his direction.

However, if he is not able to even use pencil and paper to draw his ideas or is incoherent then you need to discuss this with your management.

While they don't need to be able to write HTML/CSS, I'd argue they need to have a really good understanding of it. Admittedly, in the real world, that's not always true (some do, and can write great HTML/CSS, and some outright refuse to lean any of it) — Nov 10 '14 at 15:34
He has used Photoshop before to mockup screens. I have already mentioned more than once that my concerns have been expressed to management. I also have mentioned that we put a POC together to show him where his ideas were not going to work. — Nov 10 '14 at 15:46
@Stephen: Maybe I wasn't very clear. The goal of those mock up sessions isn't to tell him why his ideas are garbage. It's for him to tell you why they will work. This is a subtle difference and, at this point, should be done in front of upper management and kept non-confrontational. That way management can decide what to do. Either they stand by him, at which point you need to execute on it, or they quietly take him off the project. — Nov 10 '14 at 16:23
@Chris Lively: No one told him his ideas were garbage, there were patient explanations in a point-by-point breakdown. This was also documented and done with management present. He has been given ample opportunity to explain why his ideas will or will not work. His explanations have not been satisfactory and are not backed up by any research nor is there any evidence that he is a credible person. — Nov 10 '14 at 16:55
@Stephen: Then I'm not sure I understand what you are asking for. If you've tried to educate him to no effect and he's had lousy presentations in front of upper management then the only real option at this point is to fire him. If, for whatever reason, that isn't a valid option then ignore him. — Nov 10 '14 at 17:12

score 3 · Answer 3 · 2014-11-10 18:13:02Z

UPDATE: For some reason my answer has been described as "passing the buck" and ruining the software at "the expense of the user". Neither of these things is true. I have taken into account the comments below and attempted to make my point clearer.

Although the OP is the lead developer, and so has a lot of responsibility, suggesting that they train a management appointed UX "expert" how to do their job (as per the other answer) is potentially fraught with danger. Not least because the OP unfortunately demonstrated a very limited understanding of the value of UX in their question (claiming that it wasn't needed because the staff would be trained how to use his software, for example). To an outsider, this could easily look like a personal vendetta by someone who doesn't value UX input.

Especially when you consider that the OP's implication that this UX "expert" will be reporting to the OP's higher uppers on how they feel the project is getting on (even if it's only informally).

The best solution is to SHOW to management that you have taken their input seriously, and have tried your best to work with the appointed expert as best you can, but unfortunately their particular skillset is not right for the project at this time. Not just in your opinion, but DEMONSTRATABLY so.

By hiding this person's lack of skill, either by distracting them with other projects, or by "training" them, you are not only refusing to work with someone (which is very difficult to justify), you are attempting to improve the situation by covering your own ass: Your primary motivation by doing that is to avoid upsetting the manager who appointed the UX "expert". That's not a good thing for the company, who are spending money on this expert (with both their salary, and your team's time dealing with him and his suggestions) and it's potentially bad for the project, which could easily become internally contentious. In short: It's not professional.

Either bite the bullet and complain about this person's ability (not the best solution, IMO), or DEMONSTRATE to the powers that be that you've tried everything, but their input is hindering progress, and THEN suggest a solution of spending company time and money to work with them to improve their skillset.

I understand the reasoning behind "training" the UX expert without telling anyone, but I wonder how well you could justify doing so if you were called before management.

"It's not your place to help them improve in their job..." He says he's the team lead. That makes it his job. — Nov 9 '14 at 11:15
-1: I agree with TJ; the whole point is that the OP is responsible for the technical quality of the product yet this UX guy is ruining his entire team's morale and productivity. Simply ignoring it and passing the buck is a ridiculous notion. — Nov 9 '14 at 13:07
In my situation, it is my responsibility to produce a solid solution and I'm accountable for this. This will happen with or without the help of the UX guy, but it will just be more difficult due to the reasons I have mentioned before. There is also the unfortunate possibility that the UX guy will blame anyone but himself if we don't produce satisfactory results as a team. I would rather have someone with a broader understanding of the environment we are working in but that's not what we have at the moment. We just have to cope with what we have. — Stephen, Nov 9 '14 at 18:24
-1 for letting someone "hang themselves" at the expense of the user. It is everyone's responsibility to create a solid product for the benefit of the user. — Evil Closet Monkey, Nov 10 '14 at 2:25
@EvilClosetMonkey I agree with you but...this is typical in corporate settings. Which goes back to my initial comment that this issue really has nothing to do with UX. It's entirely a corporate politics/HR issue. — Nov 10 '14 at 3:19

dennislees 51735 · Answer 4 · 2014-11-09 07:45:37Z

Acknowledge the problem, make him show his notes, force him to improve

[Edit: Worked in some good advice from the comments.]

The recommendation to post this over on workplace.se is not a bad one, but this political problem has such a strong UX leaning, it's unlikely that site will provide you with the specific advice you'll find most useful.

I think it's possible to make life easier with this guy, but not before stepping up, taking on the responsibility of Team Lead, and confronting the problem head on. This suggestion isn't going to make the problem disappear, just make it more livable-with, initially reduce his input by making more work for him, and eventually increasing the chances that his input provides actual value.

Engaging in some candid communication is often the best approach in these situations, but it's not an approach without risks. The main risk being that this guy turns out to be a real asshole, develops a nice big bruise on his ego, and decides to make things even worse out of spite.

I would call this guy aside and tell him that:

As the Team Lead, and being responsible of the ultimate state of the app, I have growing concerns about the nature of the UX input - specifically with the lack of transparency into the process, and the lack of rationale provided.

I was under the impression that UX recommendations were the result of research and evaluation (user research, heuristic evaluations, competitor benchmarking, usability testing, analytics datamining, etc.)

I was also under the impression that the point of all that work, and user-centricity in general, was to provide the context in which to make design decisions, and in what you've provided so far, it's not clear that this is what's actually happening.

When it comes to other aspects of the app, justifications have to be made, rationales provided. The sales guy requesting the feature needs to provide a business case, the engineer suggesting an architecture change needs to show a cost/benefits analysis of the approach, so it doesn't seem right that changes to the UI should come without any of this. Shouldn't it be the case that UX changes, because they potentially have the greatest influence on the end users, should be based on the greatest amount of research and rationale?

When you joined the team, I was excited at the prospect of learning about the app from the UX angle. (Be careful about feigning too much interest and excitement in his role. Work on the assumption that he has a finely tuned bullshit detector, and try not to trip it) I figured we'd be seeing some surveys/interviews and working sessions with users, the development of personas that we could use through out the development process to improve decision making, user journey maps to better visualize and communicate about the app, heuristic evaluations that might show up blind spots. I also figured that you'd be backing up your intuition and experience with data from analytics and testing, and that we might end up extending and improving our analysis based on your tests.

I didn't expect that we'd be making some of the changes you've been asking us to make without at least first testing some testing of hypotheses, or showing some proof of concept. Of course I understand that there needs to be some room for creativity, and you need flexibility when it comes to problem solving in UX, but I don't think that should be the primary driver behind change.

Essentially I hoped that with arrival of a UXer, we'd see the start of an 'environment of information' in which to work and make the app awesome. The reality is that this environment hasn't emerged, and a lot of the time it feels like we're implementing your subjective opinions, which just doesn't seem like the right way to be going about this.

So, (assuming he's not completely hostile towards your position at this stage) I'd like us to start working together on building that environment. I've mentioned the few examples that I know, but you're obviously going to have a better idea of best techniques and practices, so I think it'd make sense to start with an overall evaluation of the current approach, and then possibly turn that into a proposal to start filling in some of the blanks, with the end goal being a process where our changes and additions are based in solid data, and can be backed up.

Conclusion

Pulled off effectively, and assuming this guy is reasonable, this approach should initially get him out of your hair while he goes and spends lots of cycles strategizing about how he's going to change the world, and googling what 'heuristic evaluation' means ; )

If you can take control of the situation by showing him you have a firm grasp of what it is he should be providing, but giving him perceived freedom of going off and coming up with his own great ideas, but that are delivered on your terms i.e. with backup and rationale, you turn the tables on him. You essentially reframe the relationship.

Again, it's a risky approach, and if you don't have a great deal of confidence that you can pull it off, you should ask for general advice on how to handle this sort of situation, either from your HR dept, or somewhere like work workplace.se A couple of good books that deal with the topic are Difficult Conversations: How to Discuss What Matters Most and Crucial Conversations: Tools for Talking When the Stakes Are High

The ultimate goal is that this guy will actually learn how complex and diverse a discipline UX really is and get somewhat of a reality check, hopefully leading to a widening of his vision of his role, and eventually to an improvement in the quality of his input.

All of which should make your app better, and make life a bit easier for you and the rest of your team : )

+1, but one tweak: Saying "When you joined the team, I was excited at the prospect of learning about the app from the UX angle." when in fact the UX guy was "foisted upon" the team lead isn't honest, and his BS detector may well go off. Sticking to honesty -- but constructively as with all your other points -- is the way to go. — Nov 9 '14 at 11:14
Just a quick note: neither User Experience nor The Workplace is a "board". These are not fora. — Nov 9 '14 at 13:04
This is all good advice. I would add that its necessary to start off the conversation by listening. Don't view the conversation as a way to explain your points to him, but as a chance for you each to learn more about the other person's viewpoint. If you first take the time to learn his side of the issue, you'll find him much more receptive to listening to your own view. You may even find that he would like to be doing user research but is blocked by some impediment that you can help to remove. — Nov 9 '14 at 17:55
If you don't have experience in this type of negotiation, I recommend reading Difficult Conversations: How to Discuss What Matters Most ahead of time. — Nov 9 '14 at 17:56
@3nafish Yup, good tip. Another option, and the book I refer back to most on the this topic, is Crucial Conversations — dennislees, Nov 9 '14 at 18:21

NotMe 20.9k55695 · Answer 5 · 2014-11-10 15:23:26Z

Without seeing his work, I can't comment on whether his input is useful or not. However, I can point out what a UX expert doesn't need to know: the implementation details. In other words, they don't need to be able to put HTML or CSS together.

However, they do need to know how screen layout, including things like color and font choice, can impact usability. These items might appear to be "artistic options" to you, but can have an impact on a persons ability to quickly perceive what they need to do on the page. Even just a line in the right place can help break areas of the screen up into something much more readable.

How I would approach the situation: Have him create a mockup. He should be able to do this with just pencil and paper. Bonus points if he can use something like Photoshop to put the right colors/fonts in, but that's not necessary. Once done, he should present this to the group and be able to walk through the process flow. Your job then would be to point out any missing features like "how do you delete a document?" Do so in a professional way without attacking him. Make sure he has the full expected feature list prior to drawing the mockup.

Once you have an acceptable mockup, have one of your devs through together a few screens that have the look. Then step through that, making some minor tweaks. This should result in a decent screen layout your team can throw the code behind. Execute on it, even if you think that picture in the top left corner isn't necessary. Management will judge him on it later and you'll have the documentation showing how you followed his direction.

However, if he is not able to even use pencil and paper to draw his ideas or is incoherent then you need to discuss this with your management.

While they don't need to be able to write HTML/CSS, I'd argue they need to have a really good understanding of it. Admittedly, in the real world, that's not always true (some do, and can write great HTML/CSS, and some outright refuse to lean any of it) — Nov 10 '14 at 15:34
He has used Photoshop before to mockup screens. I have already mentioned more than once that my concerns have been expressed to management. I also have mentioned that we put a POC together to show him where his ideas were not going to work. — Nov 10 '14 at 15:46
@Stephen: Maybe I wasn't very clear. The goal of those mock up sessions isn't to tell him why his ideas are garbage. It's for him to tell you why they will work. This is a subtle difference and, at this point, should be done in front of upper management and kept non-confrontational. That way management can decide what to do. Either they stand by him, at which point you need to execute on it, or they quietly take him off the project. — Nov 10 '14 at 16:23
@Chris Lively: No one told him his ideas were garbage, there were patient explanations in a point-by-point breakdown. This was also documented and done with management present. He has been given ample opportunity to explain why his ideas will or will not work. His explanations have not been satisfactory and are not backed up by any research nor is there any evidence that he is a credible person. — Nov 10 '14 at 16:55
@Stephen: Then I'm not sure I understand what you are asking for. If you've tried to educate him to no effect and he's had lousy presentations in front of upper management then the only real option at this point is to fire him. If, for whatever reason, that isn't a valid option then ignore him. — Nov 10 '14 at 17:12

score 3 · Answer 6 · 2014-11-10 18:13:02Z

UPDATE: For some reason my answer has been described as "passing the buck" and ruining the software at "the expense of the user". Neither of these things is true. I have taken into account the comments below and attempted to make my point clearer.

Although the OP is the lead developer, and so has a lot of responsibility, suggesting that they train a management appointed UX "expert" how to do their job (as per the other answer) is potentially fraught with danger. Not least because the OP unfortunately demonstrated a very limited understanding of the value of UX in their question (claiming that it wasn't needed because the staff would be trained how to use his software, for example). To an outsider, this could easily look like a personal vendetta by someone who doesn't value UX input.

Especially when you consider that the OP's implication that this UX "expert" will be reporting to the OP's higher uppers on how they feel the project is getting on (even if it's only informally).

The best solution is to SHOW to management that you have taken their input seriously, and have tried your best to work with the appointed expert as best you can, but unfortunately their particular skillset is not right for the project at this time. Not just in your opinion, but DEMONSTRATABLY so.

By hiding this person's lack of skill, either by distracting them with other projects, or by "training" them, you are not only refusing to work with someone (which is very difficult to justify), you are attempting to improve the situation by covering your own ass: Your primary motivation by doing that is to avoid upsetting the manager who appointed the UX "expert". That's not a good thing for the company, who are spending money on this expert (with both their salary, and your team's time dealing with him and his suggestions) and it's potentially bad for the project, which could easily become internally contentious. In short: It's not professional.

Either bite the bullet and complain about this person's ability (not the best solution, IMO), or DEMONSTRATE to the powers that be that you've tried everything, but their input is hindering progress, and THEN suggest a solution of spending company time and money to work with them to improve their skillset.

I understand the reasoning behind "training" the UX expert without telling anyone, but I wonder how well you could justify doing so if you were called before management.

"It's not your place to help them improve in their job..." He says he's the team lead. That makes it his job. — Nov 9 '14 at 11:15
-1: I agree with TJ; the whole point is that the OP is responsible for the technical quality of the product yet this UX guy is ruining his entire team's morale and productivity. Simply ignoring it and passing the buck is a ridiculous notion. — Nov 9 '14 at 13:07
In my situation, it is my responsibility to produce a solid solution and I'm accountable for this. This will happen with or without the help of the UX guy, but it will just be more difficult due to the reasons I have mentioned before. There is also the unfortunate possibility that the UX guy will blame anyone but himself if we don't produce satisfactory results as a team. I would rather have someone with a broader understanding of the environment we are working in but that's not what we have at the moment. We just have to cope with what we have. — Stephen, Nov 9 '14 at 18:24
-1 for letting someone "hang themselves" at the expense of the user. It is everyone's responsibility to create a solid product for the benefit of the user. — Evil Closet Monkey, Nov 10 '14 at 2:25
@EvilClosetMonkey I agree with you but...this is typical in corporate settings. Which goes back to my initial comment that this issue really has nothing to do with UX. It's entirely a corporate politics/HR issue. — Nov 10 '14 at 3:19

Search This Blog

Iyfjky

How to cope with a â€œUX Expertâ€ who has no experience?

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

3 Answers
3

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Your Answer

Post as a guest

3 Answers
3

3 Answers
3

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

How to cope with a â€œUX Expertâ€ who has no experience?

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

migrated from ux.stackexchange.com Nov 10 '14 at 11:15

3 Answers 3

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Your Answer

Sign up or log in

Post as a guest

Post as a guest

3 Answers 3

3 Answers 3

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Acknowledge the problem, make him show his notes, force him to improve

Conclusion

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

How to cope with a â€œUX Expertâ€ who has no experience?

3 Answers
3

3 Answers
3

3 Answers
3

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor