Introduce us to your team
Toolshop is the independent software imagineering practice of Julius Tarng. I specialize in helping early stage startups prototype ambitious new software with novel interfaces.
The industry draws an arbitrary line between "design" and "engineering". I believe the best products come from a tight feedback loop: design → build → test → learn → repeat. Instead of delivering mock-ups, I build functional prototypes quickly to learn as much as we can.
Toolshop combines 11+ years of product design, strategy, and creative engineering experience to help you achieve your vision.
Our bread and butter: novel interfaces, gestural microinteractions, creative tools.
What does your team's product development process look like?
I start relationships with new clients the way I spun up new initiatives as a design lead at my former companies: asking questions and framing opportunities. I spend a lot of time over email or on calls getting to know you, asking clarifying questions about your goals and needs, and giving whatever advice I can to help you — even if it means working with me isn't the best choice.
If it seems like a good fit, we'll co-write a proposal that outlines the goal, hypotheses, and potential phases of work. We'll then prototype our collaboration with a 1-week trial project, usually a piece of the project we'd work together on that's tractable in a short amount of time. Sometimes, this is doing the first phase of the project (e.g. research and strategy); other times this is building a small component of the overall vision (e.g. proof-of-concept for the biggest technical unknown).
The best collaborations leverage my generalist skillsets: all you need to bring is a vision, and I'll take care of bringing that to life through iterative prototyping. Instead of getting mockups you have to find someone to code, we'll design by building (often in React, but I've been itching to try out Svelte...). I communicate frequently and share demos to play with on a daily basis.
Sometimes, after a week or two of prototypes, a client will realize the initial thesis is not quite right, and we go back to the drawing board, together. This is an ideal outcome and I love this phase of software creation.
We'll work together until this first phase of exploration is complete. For some clients, this means helping you ship your v1.0 and shifting to a production role.
Share the last meme from the team chat
Should designers code?
I am so happy to talk about this! Design and code to me are two sides of the same coin: both are mediums (like clay or wood) with which we can speculate about the future of computing. I studied and started my career in Industrial Design, where design always worked with the final material and had deep understanding of its properties. We always purchased competing products or materials with interesting properties early in the design phase to cut up, feel, break, and remold. I can't imagine designing software without doing the same.
I've found great success in building my own technical intuition by learning as much as I can about programming and computer science, and using that knowledge to bring new initiatives to life. Many of my most successful past projects were made possible because of this ability to adjust the strategy of a project based on technical constraints and trade-offs so that we could still ship, instead of languishing in vapor-ware.
On the flip side, there are advantages to designing blissfully unaware of constraints. To move mountains, you have to first dream that you can do so. That's why I love to partner with passionate founders who need someone to make their vision a reality.
So to answer the question, I would reframe it: should software designers seek to build their technical intuition? Emphatically, yes! I'm working on a new community called Computing for Designers to help folks do just that.
Share an interesting side project from a team member
What advice would you give to people who want to join your team?
I don't have immediate plans to hire folks, but if you're considering going quitting a full time job and starting your own independent practice, here are some thoughts:
I went freelance and pivoted my day-to-day work because I wanted to be in an environment with constant learning and new experiences.
I spent a few months moonlighting part-time contracts before making the jump. Make sure to experiment: I tried a mentorship, marketing design, and product strategy projects until I found my perfect fit in prototyping.
My most successful projects are with people I knew before (industry jargon: hot leads): classmates, coworkers, Twitter mutuals.
Be generous with advice, clarifying questions, and other non-artifact-generating help when starting new client relationships.
I always start each client with a 1-week trial project to test for mutual fit.
Baseline weekly rate = compensation / weeks * 2 (to adjust for non-billable work, time between projects, insurance, and self-employment taxes). Increase this every time you get a new client.