Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Opinion Column Developers “Own” The Code, So Shouldn’t Designers “Own” The Experience?

We’ve all been there. You spent months gathering business requirements, working out complex user journeys, crafting precision interface elements and testing them on a representative sample of users, only to see a final product that bears little resemblance to the desired experience.

Maybe you should have been more forceful and insisted on an agile approach, despite your belief that the organization wasn’t ready? Perhaps you should have done a better job with your pattern portfolios, ensuring that the developers used your modular code library rather than creating five different variations of a carousel. Or, maybe you even should’ve sat next to the development team every day, making sure what you designed actually came to pass.

Further Reading on SmashingMag: Link

Instead you’re left with a jumble of UI elements, with all the subtlety stripped out. Couldn’t they see that you worked for days getting the transitions just right, only for them to drop in a default animation library? And where on earth did that extra check-out step come from. I bet marketing threw that in at the last minute. You knew integration was going to be hard and compromises would need to be made, but we’re supposed to be making the users lives easier here, not the tech team.

When many people are involved in a project, it is very important to make sure that they have a common understanding of the problem and its solution.5

When many people are involved in a project, it is very important to make sure that they have a common understanding of the problem and its solution. (Image credit: The Next Web6)

Of course, there are loads of good reasons why the site is this way. Different teams with varying levels of skill working on different parts of the project, a bunch of last-minute changes shortening the development cycle, and a whole host of technical challenges. Still, why couldn’t the development team come and ask for your advice on their UI changes? You don’t mess with their code, so why do they have to change your designs around? Especially when the business impact could be huge! You’re only round the corner and would have been happy to help if they had just asked.

While the above story may be fictional, it’s a sentiment I hear from all corners of the design world, whether in-house or agency side. A carefully crafted experienced ruined by a heavy-handed development team.

This experience reminds me of a news story I saw on a US local news channel several years ago. A county fair was running an endurance competition where the last person remaining with their hand on a pickup truck won the prize. I often think that design is like a massive game of “touch the truck”, with the development team always walking away with the keys at the end of the contest. Like the last word in an argument, the final person to come in contact with the site holds all the power and can dictate how it works or what it looks like. Especially if they claim that the particular target experience isn’t “technically possible”, which is often shorthand for “really difficult”, “I can’t be bothered doing it that way” or “I think there’s a better way of doing it so am going to pull the dev card”.

Now I know I’m being unfairly harsh about developers here and I don’t mean to be. There are some amazingly talented technologists out there who really care about usability and want to do the best for the user. However, it often feels as though there’s an asymmetric level of respect between disciplines due to a belief that design is easy and therefore something everybody can have an opinion on, while development is hard and only for the specially initiated. So while designers are encouraged (sometimes expected) to involve everybody in the design process, they often aren’t afforded the same luxury.

To be honest, I don’t blame them. After all, I know just enough development to be dangerous, so you’d be an idiot if you wanted my opinion on database structure and code performance (other than I largely think performance is a good thing). Then again I do know enough to tell when the developers are fudging things and it’s always fun to come back to them with a working prototype of something they said was impossible or take months to implement — but I digress.

The problem is, I think a lot of developers are in the same position about design — they just don’t realize it. So when they make a change to an interface element based on something they had heard at a conference a few years back, they may be lacking important context. Maybe this was something you’ve already tested and discounted because it performed poorly. Perhaps you chose this element over another for a specific reason, like accessibility? Or perhaps the developers opinions were just wrong, based on how they experience the web as superusers rather than an average Jo.

Now let’s get something straight here. I’m not saying that developers shouldn’t show an interest in design or input into the design process. I’m a firm believer in cross-functional pairing and think that some of the best usability solutions emanate from the tech team. There are also a lot of talented people out there who span a multitude of disciplines. However, at some point the experience needs to be owned, and I don’t think it should be owned by the last person to open the HTML file and “touch the truck”.

So, if good designers respect the skill and experience great developers bring to the table, how about a little parity? If designers are happy for developers to “own the code”, why not show a similar amount of respect and let designers “own the experience”?

Communication is key, so be available.7

Everybody has an opinion. However, it’s not a good enough reason to just dive in and start making changes. Image credit: Open Source Way8

Doing this is fairly simple. If you ever find yourself in a situation where you’re not sure why something was designed in a particular way, and think it could be done better, don’t just dive in and start making changes. Similarly, if you hit a technical roadblock and think it would make your lives easier to design something a different way, go talk to your designer. They may be absolutely fine with your suggested changes, or they may want to go away and think about some other ways of solving the same problem.

After all, collaboration goes both ways. So if you don’t want designers to start “optimizing” your code on the live server, outside your version control processes, please stop doing the same to their design.

(vf, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8

↑ Back to top Tweet itShare on Facebook

Andy attends, speaks at and organises over a dozen conferences a year. He loves meeting interesting people so if you see him at your next event, pop over to say hi, buy him a beer and tell him about all the wonderful stuff you’ve been working on.

  1. 1

    Russell Skaggs

    August 9, 2016 2:56 pm

    I think part of the problem you are running into occurs when dealing with “Full Stack” Developers as opposed to solid Front End Developers. A solid Front End Developer has to have a solid understanding of design and user experience to be effective and must be willing to communicate back and forth with the design team.

    That being said, while I have the utmost respect for design, sometimes projects are fixed bid. And the solution that was designed out may have better user experience, but would completely blow the timeline and budget to implement. This is especially true if a design gets approved without the blessing of the technical team to begin with.

    At the end of the day, who owns what is pretty irrelevant. What matters is the final product. And if the design team and the development team are not acting as one team, the product will suffer.

    • 2

      Marvin Hagmeister

      August 9, 2016 4:10 pm

      Couldn’t agree more. The client never cares about which team did what. The end result is what counts.

    • 3

      Riccardo Coppola

      August 10, 2016 2:24 pm

      I disagree on the “Full Stack Developers as opposed to solid Front End Developers”. Full stack is not a bad version of a Front End developer.
      Developer quality is the real problem, not the fact that a developer that doesn’t do any backend work is better at front end.

      • 4

        I believe that there is a definite need for a “solid Front End Developer(s)” in larger projects, or projects with complex interfaces. They can be invaluable as a translator between the designer’s creative concepts and the Back End Developer’s infrastructure limitations/intentions.

        Whilst it is not true in 100% of cases, a Full Stack Developer will have less front end skills than a dedicated Front End Developer. It’s the old rule of either being an expert in a limited field or a novice in a wide one. (Of course, experience, etc. will enter into this equation and may result in this rule not being applicable in all cases.)

        I have also been involved in projects where the Project Plan has budgeted plenty of time for initial design concepts to be created and reviewed, for front end mockups or prototypes to be built and tested, and then handed over to be coded out and integrated only to have a raft of changes come through once live content is being passed through the system and real users are poking at it. Inevitably, time is not budgeted for these changes to go back to the start of the process and get redesigned/rebuilt/retested, etc. and the team member doing the integration is left to try and MacGyver the designed elements to do what they need to do.

        It sucks, and it upsets the designers, but it is done to get the job over the line and functioning. I’d love designers to take ownership of the front ends (including HTML/CSS/JS), but even then, leaving the back end developers in their dungeon whilst a project is spec’d out tends to be one of the mistakes which gets made and remade time and time again.

  2. 5

    This all reduces to issues in: communications and process. Have you communicated adequately the nuance of your design both to the implementation team and stakeholders? Designers understand tacitly that small touches are in fact “part of the design” while developers tend to think in larger functional pieces. Make sure that as a designer, you are communicating it a way that resonates with developers. Call attention to details, and explain their purpose. Be explicit, and give justification, even if you should not have to. Part of being a high-level professional is being able to bridge the gaps between people who communicate in different ways. Learn how to “translate” between your discipline and the disciplines of others.

    Stakeholders similarly may not recognize that whitespace is out-of-whack, or that HiDPI images weren’t used, but only that something is “off.” Similarly, help the stakeholders to understand the importance of preserving the design into implementation. Explain the details of your design and why you made the decisions that you did. Set the expectation with the stakeholder that these details will exist, and make them want it too. If your stakeholder is expecting it, it will be much more likely to happen.

    Most importantly, design audits should be in-built into the process. Stake your claim with the PM and Stakeholders from the first moment a project schedule comes together. Do one after the initial build, and one toward the ending of testing and remediation if you can. Explain that you want to do a design audit to help make sure the final product looks and functions as well as the initial design. Again, make sure you have stakeholder buy-in; if they want it, it will happen even when the schedule starts to crunch. If it seems unimportant to them, it’ll get dropped as unnecessary fluff.

  3. 6

    Sterling Hamilton

    August 9, 2016 5:24 pm

    I’m in an agency. I’ve heard this before.

    I agree that a developer owns the code.
    I agree that a design should own the experience.

    The issue here isn’t who owns what. Ownership does not imply that you are doing a good job taking care of what you own.

    So, you now own the UX…great…now what? When you took ownership and started doing work, did you consider the timeline or budget? Did you only consider YOUR timeline/budget? Most of the time, I see designers do exactly that. They look at their landscape, and operate within it.

    A good designer, understands the medium in which they are working with.

    If you have 30 minutes to do a design, and I have 30 minutes to build it — we are on the same team. We work at the same company. We want to be ahead of schedule and under budget.

    If you take your 30 minutes, and you design a Form and change all the Shadow DOM stuff and never had a conversation with the developer as to what libraries we had that could save us time on the Shadow DOM — let’s say in this situation there are no libraries and if you had asked, you would have been told to avoid the Shadow DOM — but you didn’t so now you are done — 30 minutes of design, done on time, everyone loves the design and you “owned” the UX.

    Except you didn’t. You made the UX. Ownership would have implied that you took responsibility for the decisions you made.

    Now, the developer has to make the Shadow DOM manipulation work across all browsers including IE6 (poor bastard). It will take him all day. People are going to go “why are you over budget, this was a quick design?” and the developer is going to look at you and go “mother fucker”.

    > Developers “Own” The Code, So Shouldn’t Designers “Own” The Experience?

    Yes… I believe they should. But most designers first need to learn how to own something.

    If you buy a car, you should own the car. If it breaks because you treated it badly, you only have yourself to look at really.

    In Web Development, if you treat a Design Badly, everyone else suffers. A Designer who also has to code their Designs, knows this. Which is why they are typically more of a joy to work with.

    • 7

      I really appreciate this comment. I’m a designer first, always, but I’m familiar enough with programming to be able to know what questions to ask the developer I work with and to collaborate with him as I design. I know enough about how the web and various applications work to know to avoid some things, or implement others. I always put a lot of thought into my designs, with programmer input during the design process and design input during the programming process. As a result, we produce pretty great work, and everybody wins.

  4. 8

    Matthew Trow

    August 9, 2016 6:47 pm

    This is a classic problem and well explained in this article.

    One solution is to have a go-between ‘developer’ with an eye for design.
    They may not be a trained designer and may not be an inspired developer, but instead, manage to fall somewhere between those two.

    Perhaps a former coder turned UX expert, or a former designer with enough coding experience to cut it – someone who can work with the far sides of both disciplines.

    An accomplished designer that is highly proficient with code is rare, but there’s many levels in-between. It’s the role that, in my opinion, is an absolute must have for any team.

    As for who takes the credit for a delivered product, that is all down to effective project management. As many times as I’ve seen developers take all the glory, I’ve also seen designers take it all. The best experience is that the entire team is recognised.

    The idea of ownership should be holistic – each aspect of the project is as important as another. Brilliant programming with bad design or Brilliant design with bad programming is equally undesirable.

    Seek a combination of the two, with your ‘go-between’ developer playing the connecting role.

  5. 9

    Shane Goodwin

    August 9, 2016 9:09 pm

    This thinking should also apply to marketing/product management people at the other end of the process as well. Speaking as an ex-product manager, I can understand the desire to “own” the product and be making the design decisions, but I see this behaviour as being more widely destructive and hard to control than a dev doing their own thing. Especially as the reason tends to be “because I like that better” or “it’s what our competitor does”, even in the face of testing. Noticing I was doing this kind of thing is one of the reasons I got out of the role.

    (I should add the developers I’ve worked with are generally good at handling this; we can sit down and figure out some sort of solution that works for both of us, or at least understand why each other wants what they want. It’s seldom I see this kind of behaviour from them).

  6. 10

    Interesting perspective. I got it vice-versa right now, being something one would call a “Full Stack” Developer (anybody else, but me).

    Folks in design do 10 different variations of a slideshow (including the obnoxious half-page slideshow; with one or more text columns to the left or right), 5 of a parallax scroller thingy and so on. Just about anything is used “inflationatory”, to quote my colleague (who would be called a “Web Designer”). Its a nasty PITA and giving me lots of headaches. And then they want to “own” the design, too?

    Maybe everybody part of a project or team should sit down PROPERLY together, maybe over brunch, in a beer garden, or some other relaxing location, eat, drink, be merry, and maybe do some talk about said project or work .. and nobody would have to feel bad about the others position.

    It’s what I do with my colleague, and other folks .. and guess what: although I’m quite the nerd – it works! :)

    Just my 2 cents,
    cu, w0lf.

  7. 11

    Hopefully someday we stop talking about “UX designers” (and who “owns” this or that) and start talking about “UX Teams” instead, because the user experience is the holistic result of everyone’s efforts.

  8. 12

    As a designer I am very respectful of developers time, I am also aware of budgets and deadlines so it’s extremely important to work within these constraints.

    Over the years I have learnt to let go, step back, from my design I used to let my ego get involved but not anymore, my goal is to get the job out and up there.
    Working in an extremely agile environment I have to do this.

    Where I am employed now, stakeholders will completely change their minds at the last minute and my designs will have to radically change.

    Sometimes jobs are ‘bottle necked’ for months on a particular detail – I could amend myself – or even dropped completely after months of work.

    Occasionally I find myself stuck in the middle – between stakeholders and developers – justifying new changes to designs at the eleventh hour – the stakeholders are adamant, the developers pissed.

    I am thankful that as a designer I know enough code and UX to be able to navigate through this process. I know longer own my design.

  9. 13

    Don’t see a designer as an architect and a developer as the builder. It’s selfish and ignorant. If the entire team doesn’t “own” the experience, using the best from each team members skill set then it’s a management fail.

  10. 14

    Dmitri Tcherbadji

    August 10, 2016 5:43 am

    Sounds like a lack of leadership problem you are describing. There, a reinstatement of a problem and solution in one sentence! lol

    But consider this, nobody owns a cog in a firm, but everyone owns a piece. As mentioned above “owning a limited part of a product” would create competition for resources that’s detrimental to company’s function. Everyone is just gonna fight over time and money to make themselves look better. Bitchy.

    Instead, your CTO, CDO or even project manager of some sort should understand all aspects of development (tech and experience) and work to mediate and distribute resources, decisions and process. That’s all they are to do.

    Of course both designers and developers should voice their opinions and bring proposals but not to each other but to their project leader.

    I don’t see how a company with over 2 people on staff function without leadership. Even stoner rock bands have a frontman.

  11. 15

    Hakeem Rosario

    August 10, 2016 8:13 am

    I just want to let you know that I think you made a mistake on this sentence:
    “maybe you even should’ve sat next the the development team every day”

  12. 16

    very good observations, in the article as well in the discussion here in the comment section.

    I wondering if there’s still make sense having such a strong statement on designers / developers difference on ownership. There’s a thing to build – we can say also “to design” since the build part is made by machine, not humans. There are people assigned to build it in the right way. Everybody should co-create the appropriate solution contributing with their own knowledge.

    It seems very simple, but of course it’s not. It looks like we’re intertwined in this idea of individual roles and responsibilities that make this approach very hard to get real. Something very related to an industrial-age mindset, where there’s an assembly line and everyone has a very specific task to do.

    Our landscape looks very different. We’re creative workers (everyone, including the sysadmin folks) and we need different way to manage our process. Starting on removing boundaries between who-owns-what (and start thinking about all-spectrum cross-functional teams in action) it could be a very good starting point.

    Fences between development and operations are already falling down (devOps anyone?). Why not extend this to the full design cycle, from ideation to production and monitoring?

  13. 17

    Never once in your article do you describe the interaction of the developer in the design process. As a designer you expect to be involved in the development process, making sure the integrity of design is upheld. As a developer, I expect to be involved in the design process, making sure the design is technically feasible and also reusable, accessible, responsive (in some cases adaptive), performant, etc (Just because you can build a beautiful glass house, doesn’t mean you should).

    The sooner the developer is involved in the process, the less surprised you will be when things change (and they will for good reason if the developer is skilled).

    Experience is owned by business, product, design, marketing, dev, qa / everyone.

    • 18

      You covered it.
      I would add that the idea that the designer should own the experience is a bold statement that I would argue is not true. The last statement you, Reza, mentioned is on point.

  14. 19

    Rachel W Quinonez

    August 10, 2016 7:39 pm

    This is one of the reasons it’s vital for a senior UX role, or in the case of just one person – the only UX role, to be an individual with at least a minimum hands-on grasp of HTML/CSS. It’s not fair to the development team to create something grandiose and amazing that’s so complex and time consuming to implement it can’t be done on time or on budget. Iteration exists for a reason. The best solution I’ve found is to get in a room with the business analyst, a developer, maybe a database person depending on what’s being changed, and just hash it out on a white board or a large paper. Everyone feels included and you’re sure it’s achievable.

    A UX professional should guide the design conversation, just as a developer should guide the technical conversation, but guide does not mean dominate or dismiss. I see the role of user experience to be a processor. You take in all the data you can about your end user, their goals, the business goals, the technical limitations, and you spit out options for consideration based on timeline and budget. Sure, I’d love to have all the time and money in the world with a dream team of devs to build something that blows minds, but at the end of the day the real reason UX exists isn’t to do that. It’s to solve problems and make the user’s life simpler while attending to the business bottom line.

    Have a bigger picture vision but be open to what the rest of the team has to say. Sometimes they have really great insights and their comments lead to a much better solution than would be devised in a design bubble. And remember that compromise isn’t a bad word. A cohesive team with a single vision that ultimately steps their way through iterations to a brilliant and successful product is worth far more than winning a single design or development argument to feel superior or make a point.

  15. 20

    Yes Agreed. Designers put in a lot of effort in providing amazing designs that users would like to use. They develop the most important aspect of a website. We have seen designers working on a project of a responsive web design where they need to consider clients requirements and also have to keep in mind the user experience while delivering what is expected from them.
    The best way to approach this is to have PSD designed and test it with different users including client and then convert PSD to HTML or WordPress or Magento themes as per the requirements.
    Designing an interface is tough job and thus designers must be allowed to own the experience

  16. 21

    It might help to run the same scenario from the backend developers point of view….

    Customer comes to you and says “We’ve designed this website with FancyAgency and we need you to implement it”. Every question you have about the brief is answered with “we already covered this with FancyAgency…”.

    You get the design and it’s little more than a color scheme, some loose notes on what the new company logo might look like next year and a “scent profile” for their physical store; this is now entirely your problem.

    Fast forward 6 months and you launch the site, FancyAgency gets invited to the party, you don’t. A few weeks after the CEO congratulated everyone on a job well done you’re dragged into the customer’s office to get berated by FancyAgency on why you “ruined the design”.

  17. 22

    It’s idealistic and one sided to think designer own the experience. No one own the experience. A well designed experienced is made up of sum of parts. The experience is only as good as every part working well together. A good designer is one that can collaborate and communicate well. A good design leadership is one hat can communicate the design intent, vision and get everyone work towards it. That’s when the team can say they own the experience because they build the product together. It’s not easy, it never is.

  18. 23

    The problem with “UX Designer” is the role of “UX Designer” at this point 2016 – we should have “UX Project Manager/Specialist” that make not only make analytics, prototype, functional documentation but also Coordinate work of Developer Team he should be Project Owner in Scrum. This way “Last person who touch the truck” will be You.

    But in our world.. just imaginate that : Constructor Team build SkyScrapper with no elevator because “it was to hard – to do this, then we go with Constructor card” and now people in the build must go via ladder to the 10th floor.. Of course in the architectural plan there was nice elevator. But that situation don’t happen in real world because Constructor Teamt MUST do the build with “documentation” and also we have
    Construction Manager who Knows and check architectural plan.
    And Architect Knows puzzle that he can use in architectural plan.

  19. 24

    This is why I believe in a Designer > Developer > Designer workflow where the designers are responsible for adding the subtlety, for making the elements pixel-perfect, for ensuring that standards were followed. I like my developers to get me there 90% and then let me finish it off. It saves me from having to write 7 pages of design documentation.

  20. 25

    Nah, bro. Devs own their code, designers own their design deliverables. Making the two meet is just a matter of communication.

    If a developer isn’t delivering the best interpretation of the designer’s work (or a reasonable interpretation,) that is a laziness or communication issue that the designer and developer should try to sort out. If they can’t do it amongst themselves, then a manager needs to help.

    If anyone owns the experience, it’s the product owner, or the project owner, or the business owner. It’s whoever has “owner” in their title. Those are separate titles that can and should be assigned to whichever individual (dev, designer, manager, exec, founder) is best suited to the role.

    Good article! Developers, respect the disciplines of your designers! So much of a designer’s role is communication, though. So designers, understand that your job doesn’t end with a mockup, it ends when developers and other stake holders understand them as close to how you do as is reasonable/possible.


↑ Back to top