First, a bit about my background: I'm developer/designer who started freelancing right out of college. For better and for worse, I'm entirely self-taught, and always made it to clients what my strengths and weakness are. I was always proud of my work, and my clients and users were always happy, as well. I worked with startups for about three years before deciding to apply for a full-time job to get experience working on larger projects.

By the time I started looking for a full-time job, I had planned, designed, and built several fully functional web applications for small startups or just side projects. I considered myself to be great a UI/UX design, decent at JS, and never oversold myself. I got a great position on a small team looking to revamp their aging application to something more modern. Great coworkers, room to learn new skills and improve my programming, etc. Perfect fit.

However, once we got into the development, I realized (later than I should have) that my approach to UI design and layout is very different from my boss's, and it's beginning to make me wonder if I wasted three years learning the wrong techniques. The best way that I can describe it is this: If you were to build a web app like Slack, or Trello, or Atom (a text editor build with HTML), you would approach your layout very differently than if you were building Stack Exchange, or Github, or even Facebook. I've been building applications the "Slack/Trello" way for four years, and all of my go-to approaches for design don't apply at this company, and are shot down because they are seen as wrong. I'll spare you all the details and jargon, but if anyone is familiar with the topic, I can get more specific.

For the most part, I am looking at this as an opportunity to learn new techniques, and get comfortable working in ways I'm not used to. However, I still feel bad that I sold myself as someone who could take a feature/product from conception to production, and that hasn't turned out to be the case. It's not that I can't (I did it professionally for 3 years), it's that my suggestions are shot down as being wrong or just irrelevant. I feel as though my relevant skills put me back at entry level, or worse: "ux ninja" level.

Is this something I should bring up to my superiors, or should I just keep my head down and do my best to change my approach to fit theirs?

  • 5
    Seems kinda natural that the approaches are different. Just learn the new ways, and you'll eventually be very flexible within your field. I sorta had the same approach, except for core development. I went from Fortune 500 company to a startup, which has taught me a lot :-)
    – cbll
    Commented Mar 9, 2017 at 8:10
  • 2
    You will probably have to adjust your approach but for some things you can "nudge" your coworkers toward your approach if you have sound arguments for why they are better and can properly educate them.
    – Brandin
    Commented Mar 9, 2017 at 8:15
  • I agree that you should probably do your best to learn their approaches, but you don't need to keep your head down nor do you need to bring it up since you hadn't done it on purpose :). Commented Mar 9, 2017 at 10:04
  • Has your boss mentioned anything regarding your output etc? It sounds to me like you may be overthinking this a bit? Commented Mar 10, 2017 at 8:55
  • @AndrewBerry My boss hased talk to me about it. We've talked about the merits of building things the "Slack" way, but when it comes time to doing it for real, he's not a fan of the techniques required.
    – Trey
    Commented Mar 10, 2017 at 16:17

5 Answers 5


When they hired you they probably checked some examples of your previous projects. You are not supposed to be an advocate of a few specific technologies. You are suppose to be an expert that can bring its own background to the table and contribute to the innovation of your companies projects. Tech-culture diversity is enriching.

From this point of view do not argue in favor of a specific technique (let's say layout) just because its your familiar ground. You are in UX so you know the deal: "First know your User. And than Design for it." Use metrics, usability examples, compare with the competition, etc. You did not oversold yourself, you are just another point of view to the global expertise of your team. Sometimes your solution is the best, other times it won't be. Most of the times the solution is a composite of all insights and eventually reaches a "mature" state.

My advice is: do not focus on your differences (you did not become a worst designer overnight, neither were you fooling yourself about your expertise), focus on the final objectives. You have a target user so design for it.


No experience is irrelevant. However it seems that your approach is a bad fit for the company and team.

Learn the ropes, learn their methodology and move forwards. Your insights approaching problems from a different angle will come in handy and earn you respect later.

As an engineer I have to hit the ground running with widely different networks built in different ways quite often even though at their core they all do the same thing. The most important factor is learning and working with what is there before making any changes.



All new positions will have you learning something, but what you learned in the past doesn't disappear or become irrelevant. I know quite a few languages now, and they all work together in my head to make me more flexible. I don't use COBOL any more (who does?!), but some of the things I learned from my COBOL coding days have stuck. Ditto C++/C#, even though I work in VB.NET now.

When it comes to a new way of doing things, trust me, you will have something new every time you swap jobs. From processes and procedures to duties to code standards. The company knows it takes some time to adjust (well, hopefully) and will take that into consideration. If you fall behind by continuing to present your way and fail to take in their way you might have problems. You can turn this on its head by simply doing it their way...but turn your expertise into an asset. "I see we're doing this, and I did it that way, but in my experience I've seen that another way might be more efficient." Most bosses will listen to anything that makes a process better, even if they don't take it on, as long as you have done it their way BEFORE you make your suggestion.

"Hey, boss, I got that project done. While I was working on it, I found this other way we COULD be doing it that's more efficient and takes less maintenance."

Do it their way, tell them your way, let them make a decision as to what fits more in their strategy.


I'd say it's actually a bonus for the whole team. Groupthink only ever leads to complacency and you can guarantee at least some of your users will not think in the same way that the designers do. The more people you can involve in the design and development who have a different thought process or a different perspective, the more likely it is the end result will be successful.

Joining a new team you will always find that they do things differently to how you are used to, but it's a two way street - an opportunity for you to learn how they do things and an opportunity for the team to learn from your experience of the "outside" too.

  • The negative connotations placed on the employer having a set way of doing things is quite, well, negative, You cannot "guarantee at least some of your users will not think in the same way that the designers do." I know I love a button to be in a certain place...and users flip out when you move it. Even if my placement makes more sense flow-wise. Work with the system and allow for them to decide to adopt a suggested change, don't expect to change what they do. Commented Mar 9, 2017 at 19:09

Flexibility, learning and compromise are certainly important. But in software development I find self-taught freelancers/consultants have quite a different approach than more "streamlined" straight-up development teams*. Freelancers also know that to get paid (ie. make a company money) they should deliver what's needed as accurately as possible since unused/rejected designs/code is unpaid designs/code.

Freelancers and consultants focus on business needs and customer satisfaction besides development. Development teams focus on speed (especially nowadays), delivery and methodologies. The best companies should of course have a right balance between the two.

A rational approach would be:

  • Am I helping or disrupting teamwork?
  • What are the industry's best practices (beware of unjustified bandwagons though)?
  • How do current practices fit and benefit the company's business needs?
  • Are current practices beneficial to customers (will it increase sales)?
  • What are the tolerance levels of change within and without the organisation?

TL;DR: There is no right or wrong. Discuss and negotiate where you can. Learn and adapt if possible. But you shouldn't discount your passion, skills nor abilities. You may be destined for bigger and better things anyway, one can tell that from your question phrasing.

*If I may, I want to elaborate on this point. On the customer side, it's no point for someone to promise the customer the world and have no reasonable understanding of how to achieve that. Neither should they fail to grasp business needs and requirements. Conversely, development teams should not smash out code and use trendy technologies just for the sake of it. Yes, development teams should have freedom and flexibility to enjoy methodologies they like but they should be aligned (an overused word, no doubt) with customer satisfaction and external and internal business needs. Who knows, maybe down the line you're the person to bridge this "gap", if it exists ;)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .