Overall I would consider myself a digital nomad, both in terms of geography and skillset. Whether it's a new city, a new role, a new technology, or a new company (maybe yours!), I'm perpetually excited by change.

Below are a curated selection of three projects that I think are worth looking at, whether it's because they're current or because I'm proud of them. If you want to see some more things, hit up an older version of this page at jjcm.org/portfolio.

Currently I'm a design manager at Atlassian. My main role is leading the creation / curation of our design system. Atlassian's Design System is one of the best in the world and is often listed in examples of great design systems (seriously, just google "design system examples" and see how often we're brought up). This has been the result of a great team but also a great strategy. We truly consider our design system to be the foundation that we build our products upon at Atlassian. Currently I've been leading a push to tokenize our design system to allow for semantic mappings of colors. The goal with this is not just to allow for accessible themes (dark mode, high contrast mode, color blind modes), but also to make our system even easier to use.

Tokenization & Themability

We've recently had an internal mandate to make accessibility part of our DNA at Atlassian. In order to properly adopt this mandate, we needed to have the ability to support accessible visual themes that could easily propagate through every product in our system once the user chose to enable one. This was especially important in a post-coronavirus world. More and more people are suffering from photophobia due to increases of screen time, increasing the need for dark modes in our products.

The answer to these problems was a full tokenization of our design system. Semantic tokens allow for simple mappings of colors to their use case. In designs and code, employees then just select the token that represents their use case. This means all we have to do to create a theme is override the token values, and voila - the theme is present on every product that has implemented said tokens. This has been a tremendous amount of work that has required the organization, planning, strategy, and collaboration of every product under Atlassian's umbrella. It has been the primary effort I've been leading this year, and we're excited for it to ship soon.

Figma Migration

Recently I lead our migration to Figma internally, requiring the collaboration of design, legal, procurement, and leadership. After extensive research we migrated 300 designers, providing them with training courses, plugins curated to their work, and fresh new GUI packs to use with the new tool.

According to our internal CSAT surveys, the migration to Figma along with the training and tooling we provided to go along with it had the highest satisfaction of any internal platform effort in all of design at Atlassian. A lot of this had to do with something I'm particularly passionate about - tooling. Without the right tools to get them off to the right start, the migration would have been much harsher.

Design Plugins & Tooling

I lead our internal design system tooling team withh a mandate to reduce design friction. Our designers had a myriad of repetitive tasks that they did, leading to reduced efficiency and enjoyment. If you want a deep dive, here's a talk I gave at Figma's Config conference talking about this journey.

In summary though, we ended up saving over 30% of design time with the plugins, totalling 18,000 design hours saved to date.

Data Generators

More than anything else, the biggest time savers were the data generators. Simple plugins to fill product specific data into our designs. One issue we had with traditional generators is there wasn't always a clear license for images being used. To circumvent this, we used a neural network to generate fake avatars for insertion into design. This was a process based on some research nvidia put out that slowly scaled up a series of random pixels, each time using a scaling algorithm that was biased towards the look of a human face.

In the end we generated over 1000 faces, eventually selecting 5 that we felt represented a wide amount of diversity. We called this our Atlassian Hero Pack.

These heroes were combined with other bits of linked data such as names, emails, usernames, and job titles to allow for easy creation of user data:

Design

The design has gone through several variations. I originally made a very small interactive prototype to pitch the product idea to two incubators (ycombinator as well as one ran by the Australian government). While I was offered funding by the Australian incubator, I ended up turning it down as I wanted to ensure that the product was for the creators, not the investors. That's one of the issues with current platforms - they build out for the advertisers because they are the paying customer. Youtube recently demonetized history and lgbt videos at the behest of the advertizers, effectively destroying those categories on their platform.

After this, I tried making a full site prototype to figure out the UX of the platform. I didn't try and take long with this from a dev or design perspective, as the purpose was just to feel things out.

Eventually it landed where it is today after a bunch of design itereations in Figma, with tons of help added by a fantastic designer who you should also hire, James Rotanson.

If you're curious to see the current state, check out a post on the site that's live: https://non.io/painting. You can also log in with the credentails asdf@asdf.com (password = asdfasdf). The site is a WIP and is often changing, so I cannot guarantee the stability of anything.

While I'm waiting for the backend development to wrap up, I've been working on small micro-interactions. Small things to add rich amounts of pleasure to the usability experience, such as the details on the signup form.

Development (frontend)

Frontend develoment is a passion for me. I really wanted to stretch myself with this and code everything in pure javascript with no added libraries. This was for a few reasons. One was that I see an anti-pattern in javascript of over-reliance on libraries, leading to lazy coding. The other is the slow creep of pageweight and downgrade of performance on webpages. A great example of this is Jira, which has a page weight of over 30MB. To me this is an unacceptable tradeoff of convenience of development in lieu of better user experience.

Very early on I settled on using webcomponents as the building blocks I'd be using for the site. As a native browser feature, it meant that others could easily incorporate those blocks in any frontend, regardless of the frameworks being used. Go ahead and check out some of the webcomponents I've made for the site. Some of the things I'm proud of in this are a tiny implementation of event and binary attribute binding similar to React or lit-html, as well a webcomponent based client-side router, that I eventually split into its own dedicated library I call Capacitor JS.

Overall, my quest of no required libraries ended up failing, as I gave in and am now using QuillJS for rich text editing. This was not an easy decision as it tripled the size of the site, but rich text editing is an extremely complex problem with many pitfalls. At some point you have to make compromises with any project, and this was one I had to make to ensure the UX of the site.

Development (backend)

Much like the frontend, I started with a small prototype of the backend API server, then moved to a more production format. The first version was a simple node.js based server that was my playground as I was creating the rich documentation around the endpoints.

Once I was satisfied with the design and architecture of the endpoints, I moved to a more production robust implementation in Go. I hired Kurtis Holsapple to lay out the foundation of this Go project. Currently we're still in the process of finishing the Go implementation. Feel free to follow development of it on Github.

Onboarding Prototype

We wanted to find a way to better on board new users and show them the latest and greatest features. What we came up with was a method of showing a second virtual mouse on screen that showed the user a process, then had the user perform the same action. It tested incredibly well and was eventually integrated into the products.

Bowtie Prototyping Server

Designers often have issues prototyping in code. It often has far too high of a ramp up to even get started that just the setup can be daunting. In order to combat this and to increase the adoption of prototyping at Atlassian, I went ahead and built out an electron based prototyping app. We called it Bowtie, and it had several features that contributed to a much larger adoption of code based prototyping.

Pre-Built Static HTML Templates

To kickstart the process of letting designers prototype in code, we made static html representations of our products. This meant that designers didn't need to learn React in order to start making things work in usuable products.

Ak-Lite: A Webcomponent Port Atlaskit

React seemed to consistently be a barrier to designers coding. With the static html templates, it was much easier to get started, but it was also very difficult to consume our React-bsaed component library. To help with this I built out aklite, a collection of all of our components, remade in webcomponents. With no libraries needed, it was as simple as typing <ak-calendar></ak-calendar> to insert a calendar component that was fully usable. Docs and a sandbox are located here if you want to check it out: https://prototype.guide/aklite

Hi, I'm Jake, aka jacobjoseph cameronmiller*

Atlassian Design System