I build quite a bit of projects with a friend of mine, but we always come to the same pitfall over and over again. I know how to write PHP, Javascript and all that of stuff (I also know CSS and HTML) so I can do most of the work when it comes to building the actual functionality. However, he can't, but he can do something I barely can: design the sites.

But every time, we stumble upon an issue, since he doesn't know how to write code, it generally slows down our development quite a bit. At the moment this is our workflow:

  1. We come up with a feature
  2. He builds the front-end design (where it should be placed, how it will look etc.)
  3. He sends the complete template to me (the HTML export from Pinegrow)
  4. I look for the changes he made, then implements them in the actual site (since a few weeks, I use CakePHP for it).
  5. when something doesn't work out as intended (like for example, it didn't work out as we planned for some reason), I fix the issue on my side, then send him the template back
  6. rinse & repeat

This process, as one could imagine is painstakingly slow and inefficient. So my question is, how can we make this process go smoother? I've seen a lot of stuff about that we should use React and use RESTful and what not, but we want to use CakePHP for it. Could some people guide me to some helpful resources about it? I've been looking for this for a while now but never came to a decent solution for this.

Basically, all my partner can do is designing the site. He can't use Docker (I use Docker all the time), PHP, Javascript and pretty much anything else (he does know some CSS, but mostly works with a WYSIWYG editor) I'm willing to learn it to him, but he is not interested (so I have respect that). I hope somebody here could help me (and probably others coming by this question later) out with this as I think it's quite a major thing.

  • 4
    I don't quite understand what your problem is. This is how Separation of Concerns works; he writes the template in HTML, you write the rest. He shouldn't need a Docker container to do that, nor PHP or Javascript. You're already doing it the best possible way. If the problem is sending it back and forth, put the whole project into a Github repository and share it (you need source control anyway). Commented May 19, 2018 at 14:15
  • 1
    Unfortunately that's the nature of iterative development. Things change. If the issue is that he sees the completed, working design and decides to completely change it, then you need to tell him to give you designs that are already pretty close to the actual finished product. Commented May 19, 2018 at 14:18
  • 1
    Yes, I have to copy all the changes to my code and add the dynamic stuff in (like forms generated by CakePHP n stuff). If I just use his templates directly, I lose all the PHP code that I already put into it Commented May 19, 2018 at 14:31
  • 2
    Can you sit together in one room, using one computer, and integrate your work? Pair programming can be super effective for these kinds of problems where you need to bring two skill sets together.
    – amon
    Commented May 19, 2018 at 15:07
  • 3
    @FinlayRoelofs then you might consider learning how to use git. You should each checkout each other's code before pushing your own, then you're always on the same page.
    – Zymus
    Commented May 19, 2018 at 23:22

6 Answers 6


Want to free your Front End Designer from the code? Want to speed up integration? Want to use the professional techniques used by the slickest web sites? By far, the best tool for this is:


Yes Paint. Well some drawing program anyway. Let him take screen shots of your site, move things around, and add things he finds elsewhere. This will let him work at the speed of his ideas and free you to bend the code into whatever shape works best for you while giving him what he needs.

If that's still too slow, say because the customer is in the room with you both, I recommend a much more advanced tool set:

Paper, scissors, and tape.

Maybe a pen if you're feeling ambitious.

I've used this technique to successfully get decisions on the theme, style, content, and major features for a site at a table in a Panera Bread with a customer before anyone realized we were done eating.

That will make him fast, it will free you from his "code", and it's actually the most powerful way to develop a user interface. He can start doing usability tests before you've written a line of code.

You may be thinking "oh this is fine when getting started but you don't use this once the site is developed". Not true. It works just as well on stable sites. But now most of the screen shots come from your own site.

What if your Front End Designer wants to use some code generating tools to make his mock ups? Fine but don't think for a second that you have to use his "code". What you need to respect are his decisions about look, flow, and presentation. What happens behind the curtain to make that happen is not his area of expertise. It's yours. Take responsibility for that.

Just respect his work enough that when you're done you show him how it turned out. Let him nitpick everything the user would experience. Be prepared to get hit with new ideas.

This is iterative development. Don't do a lot before asking. Do as little as you can. Ask as often as you can. Put toys on your desk to keep him entertained while you implement his latest idea so he can review it as soon as it loads. Keep going like this until it's time to meet with the customer.

If the code your Front End Designer produces is actually worth the trouble then you need to learn to integrate your code with his. For this I strongly encourage you to learn source control. Learn it so well that you can teach your Front End Designer how to use it.

Only once both of you can reliably use a source control tool do I recommend that you base your integration plan on merging code. At this point your friend would deserve a title change from Front End Designer to Front End Developer.

Now even if you do this, it wouldn't surprise me if the doodling-on-screen-shots technique doesn't still turn out to be the fastest way for you two to collaborate.

Maybe you just can't take the chaos of all these changes. It's creating too much work. Well it's called software because it accepts change. Otherwise we'd have an Electrical Engineer do it on a specialized chip. It could be you need to reachitect to move your behavior logic out of the user interface so UI changes won't impact your core business rules. If you speed up your Front End Designer you need to be ready to keep up with them.

The only good reason to force a Front End Designer to produce code is because you're tired and want to slow them down. Well, I guess that's not really a "good" reason.

  • I see what you say, but the thing is, there is no customer. We build the projects by ourselves (generally we come up with an idea and try to build that in an actual function thing if we thing it's actually doable for us). We already use Git for most of the things, but I still have to add the changes manually (doing a marge ends up with either my or his code being sorta pretty much ehm... gone) Commented May 19, 2018 at 20:39
  • 1
    Then the customer is each and every user. Anyway, if this is true: "since he doesn't know how to write code, it generally slows down our development quite a bit." then stop making him work with code. Try it the other way. He will cause you nightmares without knowing why if you keep making him think he has to give you code. There are really awesome people in IT that never touch code. Give them some respect. Let them do what they love so they can shine. Commented May 19, 2018 at 20:55
  • 1
    I have used Powerpoint for this - think paint on steroids. I used slides to show sequences of work flows etc....
    – mattnz
    Commented May 20, 2018 at 5:34
  • 2
    @mattnz sounds awesome. The most important thing is to bend the tools to your purpose. Not let the tools dictate how you are allowed to solve problems. Let me do my own thinking. Commented May 20, 2018 at 5:38
  • 4
    +1, the core issue here is the friend using Pinegrow and them expecting that to easily integrate.
    – Paul
    Commented May 20, 2018 at 13:59

In terms of tools, the optimal workflow I've see is using Sketch and Zeplin. Sketch is a straight-up design tool. Equivalent to Photoshop or InDesign, but optimized for designing apps and web sites. Zeplin is a tool for sharing and approving designs in Sketch (or Photoshop). It can give precise pixel measurements and even code snippets for CSS or other layout code and export graphic assets. Once a design is set, it is handed off to the developer. At this point, the developer picks it up and builds the UI. Then it can go back to the designer for visual QA. Anything he finds wrong with it, should just be logged as a bug to be prioritized and resolved by you.

  • That does look interesting indeed. Too bad that they are somewhat expensive (especially since we make about 1 or 2 bucks a month on our projects, we are doing it just for fun), I'll definitely keep them in mind if we start making money (for some reason). Commented May 19, 2018 at 23:19
  • Zeplin is still free for one project. Sketch is $99/yr which is pretty modest.
    – jiggy
    Commented May 28, 2018 at 18:53

when something doesn't work out as intended (like for example, it didn't work out as we planned for some reason), I fix the issue on my side, then send him the template back

That's the root of your troubles. The flow of design should always be from Designer to Developer and never reversed. Revisions and changes should have been made by the designer, and then pushed to you for implementation in the website. You can always make fast fixes yourself, but try to accept that those fast fixes are just temporary. The designer needs to go back to his designs and figure out the proper solution. He then pushes the change to you, and if it happens to be the same as your quick fix then great, otherwise you update from his designs.

He sends the complete template to me (the HTML export from Pinegrow)

Don't become addicted to receiving HTML you can work with. It's better if you implement the website technology (Bootstrap, CSS, jQuery, React, PHP, etc.. etc.. etc..) the way you need it. You then reproduce his designs using those tools. If the HTML he gives you is a quick start then great, but later as the project grows it won't be of much use. You'll need to make the changes yourself because only you understand your templating engine (i.e. CakePHP views, templates, plugins, component, etc.. etc..)

This process, as one could imagine is painstakingly slow and inefficient.

It's always been that way. Designers aren't programmers. They take their time to figure out what works best for the user, and sometimes they make mistakes. They don't understand concepts like components, frameworks and such. As the programmer you have to speak to your designer and share the how I implement what you design.

The designer is stuck in the middle. On one side they must please the needs of the programmer, and on the other side they must please the needs of user.

So my question is, how can we make this process go smoother?

I've found that physically sitting beside the designer and programming there really helps with the communication. If you two are working remotely, then keep facetime running for a few days. It really helps speed things up.

I've seen a lot of stuff about that we should use React and use RESTful and what not, but we want to use CakePHP for it.

CakePHP is one of the best frameworks on the planet (full disclosure, I'm on the CakePHP core team).

Cake is a rabbit development framework where the features are designed to build websites quickly. I know that sounds like a sales pitch, but this is what it is classified as. There are many other frameworks that are classified as rabbit. Java would be an example of a framework that is more enterprise than rabbit. If you were using that language, then I would have made a recommendation to change. Since you're using CakePHP. I would argue you should stay with it.

CakePHP makes for a good back-end server if you need RESTful APIs.

React/Angular/Vue are all popular and trending front-end frameworks, but they haven't been around for very long. CakePHP on the other hand has been around for 13+ years. My point isn't a criticism. It's the fact that these JavaScript libraries have a short shelf life. In 5 years we'll all be talking about something new, but I suspect CakePHP will still be around.

So I say. Use React/Angular/Vue now while their hot, but don't get to committed to them. Something new and better will be along shortly. I think we live in a world now where you can't build good websites without them.

Could some people guide me to some helpful resources about it?

Requests for lists are off topic here. Sorry.


I missed the part about tracking design changes.

Have your designer save his HTML output in BitBucket (they have free private repositories). You can then track and do comparisons using the BitBucket website. Everytime the designer makes a major change he adds a new branch with a version number.

It should be relatively easy for him to do this, and this will allow you to have a place to comment on said changes. For example; he can make a pull request to update the repository where you perform a review of the changes before they are merged.

  • 2
    By Grapthar's hammer! Would you people explain your downvotes?
    – radarbob
    Commented May 25, 2018 at 17:57

You need to separate these two things:

  1. UX & UI design, a non coding activity
  2. Implementation, definitely a coding activity

The designer should use creative tools like Marvel which are just for designing. It should not be designer's concern to do anything with code, HTML, CSS etc. The colors, dimensions, aesthetics, interactions, animations are all the things he should be focused on.

The programmer should receive the assets and the mock-up (with interactions and animations) and should make it happen by programming the software. This included HTML and CSS as well. The programmer can use generator tools on his side as well.

To speed up task flow, I recommend to use a minimal tool like Trello and link/document everything for each work unit.


how can we make this process go smoother?

Insist on version control

Software Branching and Parallel Universes

  • Work on no code not in version control. full stop. And I mean go on strike until the project is all in a VCS.
  • Branch formally, liberally, locally
    • Formally: branching for releases and sub-parts of releases, formal testing fix, etc. Evolve a formal version control plan, i.e. write it down.
    • Liberally: Beyond 4-part formal release numbering, branch if your gut tells you it might be a good idea.
    • Locally: I kept a personal repo with branches never intended for team consumption because as a team we did not branch at first, and I often have experiments, exploration, just in case, etc.

Engineer the hell out of your middleware APIs


  • Stability - even when the underlying code is evolving.
  • Testable code
  • Re-use
  • A team communication tool
  • It's a contract. A promise of services rendered (pun intended)
  • Coding in the realm of SOLID == happy maintenance programmer

It's the ask, don't tell principle applied in the obsessive compulsive way it should be. If the UI is manipulating a single business layer property, that's wrong.

Everything and anything about the business objects must be in said BO's. Even trivial things that may seem best done in the UI - even a single LOC. Minuita like adding 2 user-supplied values - all associated logic including validation must be in the business layer API. IMO redundancy is sometimes OK. To mitigate redundancy maybe have small, focused business layer objects that the UI is allowed full access to.

Everything and anything the UI needs from the business objects should be API'ed. For example have explicit methods that wire its argument(s) to event handlers.

Beware of frameworks as a crutch

In the hands of the unskilled, frameworks and IDEs are not barriers to the B-movie monsters they create.

With frameworks like React you might say it's all client side, there is no back end business logic layer. The key idea here is decoupling what the user sees from what the program does. That's doable. It's not just a physical server vs users' browser thing.


I think it’s a good indicator of the immaturity out of profession and practice that we accept that people who design, cannot do.

This would not be acceptable in nearly any other profession.

It’s reasonable to expect a designer who specializes in web site/app design to know CSS and HTML well enough to provide you with working and usable files of that type.

Designer who provide WYSIWYG graphical editors are visual or graphic designers. There are many different kinds of designers.

However there also many different kinds of skills levels, abilities, and experiences. One who designs furniture could do it solely on a computer with 3D design tools, in which case their knowledge of how to turn a lathe or operate a CNC router might be wholly theoretical. They do their designs and then send them off to be made by others.

Conversely some expert designers may have control over the entire process and have the ability and knowledge to build their furniture with an eye to every detail, perhaps even hand-craft.

You will not be able to convince your friend to change their way of working. If you would rather have a web designer with the HTML and CSS skills to build their own designs, you will need to find one.

  • Downvotes are hilarious. I guess this is some kind of sacred cow? Commented May 19, 2018 at 19:47
  • Thing is,the files that he delivers to me are completely workable HTML and CSS files, but I have to search for the changes (easily done with a diff tool) and then manually implement them the way we wanted to. Commented May 19, 2018 at 20:41
  • @FinlayRoelofs what do you mean by “the way we wanted to”? Why not then talk to the designer and ask them to write the design as the team desires? A professional should be able to learn and adopt the practices of the team. Commented May 19, 2018 at 20:43
  • We are just a 2 man team. We come up with something (like for example, we want a page to have all our products in a showcase) and together we make plans on what we want in it and what it should do. He then designs the thing in his software (in the meantime, I'm either cleaning up what I already made or go fix issues). Once he's done, he send the template to me after which I do my thing (make it actually do something). Commented May 19, 2018 at 20:47
  • @FinlayRoelofs I’m confused then. Sorry. Either you need to accept that you’re just a two person team and decide how much time you want to spend on rewriting or accept the quality of what they deliver. Commented May 19, 2018 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.