What's a design technologist?

I'm now in my 3rd "Design Technologist" role - this time at Rocket Mortgage. I've also been at Square - yes that one where Jack Dorsey fired everyone - and a small Architecture & Engineering technology consultancy called  EvolveLAB  that has since been acquired . All three roles have been slightly different, and always in different ways at that. Same same but different if you will. In the rather vague parlance of this world, you might say that EvolveLAB role was perhaps more of a Design Technology role whereas, at Square, I was perhaps more of a Design Engineer. The team at Rocket falls in the middle. But even that is unfair as I felt with tooling and technology at Square. And I certainly engineered at EvolveLAB. There's just too much variety and fluidity to pin anything down in an absolute sense.

But in case you're looking to learn more about the design technology role or trying to understand what I can do and/or have done, below is a bit of an outline into what I've done in my career as a design technologist.

At Rocket Mortgage

We're a brand new team at Rocket and this are still trying to figure out where we stand as a team. As of now, the team lead comes from an AI and startup background so the work has tended towards production/implementation of tooling and the augmentation of process via technology. Perhaps that will remain the same in the long term route or perhaps we will start to adopt some more creative engineering projects as well. Time will tell. Our big endeavors so far have fallen into the buckets described below.

We've supported the Design Systems teams in both design and engineering. I have operated as a designer and approved a few engineering implementations of design systems components. I have also operated as an engineer and built a few components that designers (and engineers) in turn review. My teammate has had much more of a focus in this area - using her design systems background to implement a larger number of component than I as well as in starting to translate the system over to a production version of our AI chat environment. This collaboration with design systems does seem like a usual spot for Design Technology to sit based on job descriptions I've seen flitting around the internet.

My focus has been much more in the tool generation side - I was pulled out of design system work earlier to bring focus back to tool development. Our first project was actually a Figma plugin (as outlined in this case study on LinkedIn by our team lead). Since then, I've ported over a Figma plugin template for us to use (it's an offshoot of this basic template I built in my personal time a bit back) and then started work on a much more complex, LLM-powered Content Design plugin for Figma. That one is slowly rolling out to our design teams now in a release, research, iterate cycle to work out the kinks. AND there is yet another Figma plugin in our pipeline as teams start to come to us for that as well. This may end up being a huge focus for us almost by default as people realize we can build helpful stuff for them.

We've also worked through some other minor projects along the way such as a small motion exploration page, Figma Make templates, and more. But mostly, it has all remained internal with a focus on tooling and process. We shall see if that evolves over time.

At Square

At Square, my role can be thought of similarly to what I discussed in my Design Engineering piece. That piece did, after all, come about due to a post I came across on our Square DT Slack channel as others were trying to nail down how, exactly, to describe our role relative to industry standard titles.

Generally though, as DTs at Square, we sat within the Design Org and work directly with brand creative teams to create web experiences that would tell the story of the various products that Square provides. The extent to which we were involved within the nitty-gritty of the design process versus silo'd off as more of a pure frontend engineer varied on a per team and per project basis.

I've been involved very deeply within the design process for some projects - such as the (since changed greatly so here's a web archive link) Square Specialist Directory - where I was even directly responsible for designing various elements on the page. Being this involved also greatly improves the page build process where I can start laying out the code in my head before the build even begins. I can work with the rest of the creative team to ensure that what is designed is feasible or even push the envelope further when their ideas would be easy to take to the next level. (Mentoring designers on what is possible and what is not, where we can push and where we need to pull back, is another key feature of the job.)

I've also been brought in much too late on other projects - the Developer Homepage comes to mind here. Our creative team was organzied in such a way where this was nominally a "creative" arm and a "production" arm. Though, as shown with the Directory above, we did have some design responsibility, the "high visibility" projects were kept to the "creative" arm of the team. The result was an incomplete hand-off and idea that the page could be built much more quickly than it, in reality, could be. My limited involvement meant that I was not around to discuss features such as responsive design or animations/motion where content was interactive. This lead to a timeline that was far too short because the full complexity of the design was not understood as the page moved from a static Figma file to a real, live page. Ealier involvement from me, or another DT, would have smoothed these issues as we could have, at the very least, educated the design team and guided the discussion on what was needed to bring their ideas to life.

I guess this is my long way of saying that, as a Design Technologist as Square, my role was narrow in one sense: use our engineering skills to craft beautiful web experiences. But it is also broad in another: we are also designers and educators. When used to our fullest, we were asked to bring our own design ideas to the table, educating/guiding our designers and pushing them further to the boundaries of what is possible on the modern web.

At EvolveLAB

My experience at EvolveLAB was much different though it may be familiar to those involved with the technology side at architecture and engineering firms. While it is true that I got my frontend engineering start there - at least in a professional sense - my role went far beyond the web. In fact, it was not until relatively late that I got into engineering web applications and web-based frontends. This role was linked much more closely with my background in architecture in terms of the clients we supported, products we developed, and the general software we worked with regularly. And it more or less required me to work with any sort of technology that made sense for said clients be it Revit and Rhino modeling or full-on software engineering.

My role at EvolveLAB started at a relatively basic level: I was tasked with building out Revit families. It was not glamorous work but, at that time, EvolveLAB was just starting to dip its toe in the water of software engineering. A few sets of Revit families - casework, windows, and doors if I recall correctly - were what was paying the bills back then.

I was able to quickly move into more complex roles. At that time, when software building for me was at the hobbyist level of watching online courses, "complex roles" meant pushing the boundaries of Grasshopper and Dynamo. I made quite a few scripts for clients. I very much enjoyed the work. I'm not sure that I would as much now. Not when I can just as easily write code. But back then, it was great work. It allowed me to slowly dip my toe in the water of software engineering.

My first professional coding experiences, I'm not counting a couple scripts I wrote for small web projects we took on at RINKA+ , were a part of those old Grasshopper and Dynamo scripting days. I wrote many a custom Python node for Dynamo. I eventually graduated to writing more robust and more complex C# plugins for Grasshopper. One such project was to build a script out for the team building the Lucas Museum in LA that helped them track panel construction and delivery. That script pretty much turned into a set of custom Grasshopper nodes. The code was pretty terrible if I'm being honest. But it was something!

We quickly leveled up from there. I joined a small group of EvolveLAB-ers that were building a much more complex mini-application - okay fine, it was just a very complex Revit plugin but still - for a Michigan-based metal panel manufactuer. That code was also... not great... But we learned a lot and leveled up quickly as we worked. This experience really got me ready to lead a generative design, web application we built for an architecture firm client. It was my first professional web app and it opened a lot of doors. I built the first UI for Helix after that. The rest is history. That pretty much got me to where I am now.