There's not much written on succeeding as a UX Engineer and there's even less written on how to do it as a freelancer. I'm going to anecdote my top three rules for a successful engagement.

‍Rule #1 - You can't work without mockups

UX Engineers translate user interfaces into code- which means if there are not any user interface mockups or concrete design decisions in place, it's impossible to do your job correctly. These mockups not only determine an engagement's deliverables but also play a key role in helping you scope pricing and form timelines. Unfortunately, wireframes or napkin drawings just won't cut it - you'll need something high fidelity to work against, preferably delivered in a Figma, Adobe XD, or Sketch file. Moreso, the mockups should contain both page and individual component level designs.

With that being said, It's important to recognize that our line of work is still a bit nuanced to outsiders. It's quite common that a potential client wants to mix the design and engineering of their user interface into one engagement, and no amount of reasoning can undo their mental amalgamation of the two.

You and I both know that designing user interfaces is well outside the scope of most UX Engineers skillsets, but that's not exactly the answer that gets you hired. If you're not in the business of turning down new clients, I suggest a more refined response in these situations.

First, do not be tempted to do the design work yourself. I know we're creative and I know we own a subscription to the Adobe Creative Cloud. But the fact of the matter is that most of us can't deliver design work on a professional level - in the same way UX Designers can not professionally deliver HTML/CSS/presentational Javascript.

Instead, I suggest that you respectfully but firmly let any design-less potential client know that there's good news and bad news. The bad news is that you can't start developing the user interface before you know what it is - and that they will need to work with a UX designer first. The good news is that you're excited about the project and you happen to have a recommendation for a UX Designer that is perfect for this part of the contract.

If you don't actually have such a relationship with a UX designer - I highly recommend forming one before you start soliciting contracts. Whether this designer is a subcontractor to you or a direct contractor to the client is a personal preference and can vary from one engagement to the next - but I recommend against insinuating that you will be doing the design work yourself. Not only is transparency the foundation of receiving future engagements, it's also important that the designer be able to communicate with the client directly - something that's impossible if the customer doesn't know the designer exists.
‍

Rule #2 Develop in isolation

There's a fascinating phenomenon in the world of software development, where independent contractors rarely if ever do their contracted work independently. Instead, the industry norm is to work through an embedded team model. The contractor walks, talks, and works like a W2 employee - attending standups and making collaborative contributions to fluctuating priorities rather than individual ownership over predetermined isolated deliverables. While this may work for other parts of software development, it's not particularly well suited to delivering the highly specialized and fixed scope work of user interfaces.

A much better model to adopt is the tried and true method used by our creative counterparts in UX design. That is, collect and collaborate on requirements, work independently, and deliver a consumable end product that checks the boxes. In execution, this means having total ownership over delivering exactly what was promised by working from within an isolated code repository.

If you aren't already, it's important to become familiar with a tool like Storybook or Stylegudiest, which will allow you to develop user interfaces independent from the rest of the front-end codebase. Isolated development allows you to better control the onus of your own engineering deliverables by removing external blockers like PR approval, merge conflicts, and well-intended but misguided collaboration efforts. Additionally, it helps shield you from out-of-scope, 'back of the front end', application logic. It can also help secure contracts with companies who have confidentiality concerns in sharing their primary codebase with an outsider.
‍

Rule #3 - Scope and price by component

Any client can appreciate transparent pricing and rock-solid delivery estimations. For traditional software development contractors, the embedded collaboration model and the unpredictability of application logic make it difficult to offer. Fortunately, UX engineering is not only immune to those constraints (see Rule #2), the nature of our work lends itself quite well to semantic scoping.

Every user interface can and should be broken down into a collection of reusable components. These reusable components cannot only be developed independently from one another, they can also be scoped independently. Three billable hours for a button. Five for a validating text field. 10,000 for a spinning-inverted-autocomplete. So on and so forth. This breakdown leverages the visual nature of our work to assist the client in understanding where the money is being spent. Additionally, it can help the client replace high-cost / low-value components with better alternatives.

One caveat to scoping-by-component is that you should briefly break this pricing model for line items like 'Initial Discovery and Setup' or 'Design Review'. That way, you can ensure compensation for the small bit of technical overhead that comes with setting up a new engagement but is not represented by any one component.

‍

That concludes my rules of engagement, but not necessarily our conversation. If you're a UX Engineer with some thoughts or a potential client with some opportunities, reach me at himself@thejonathanfox.com

‍