Grokking a new industry
Learning 10 different jobs in a week
One of my favourite and simultaneously least-favourite parts of my work is starting a new project in a new industry.
First you learn the language:
- Leasehold vs Freehold,
- EBITDA,
- Capital Contribution,
- Fixed vs Rolling vs Recurring breaks.
Next you learn what each person does, and how they do it. If only this were as simple as learning which title correlates with what work, but often two people in the same role will have completely different day-to-day experiences. I had 5 days to learn what 10 different people learnt in 10 years each—it was exhausting, but challenging in a way that I love.
I flew to London and spent the first week wrestling with understanding this foreign industry. We whiteboarded, sticky-noted, wireframed and interviewed. We emerged with a decent understanding of how all of these different roles interacted, the common elements we could lean into, and had a clear path forward.
Almost none of the decisions we made in this week survived MVP intact, but that doesn’t in the slightest mean the week was useless. Rather, the decisions we were making here were a way to link everything together enough to start doing work.
Learning React
And falling in love
I’m a designer who codes. I’ve worked with various Javascript frameworks over the years, but this was my first experience in React. And it was love at first sight. Suddenly I was no longer wrestling with the design principles of atomic design against the global nature of CSS, or the local/inline nature of HTML.
Because I found React so intuitive, we began coding immediately—during the first week. One of the benefits of being a-designer-who-codes is that I can operate on 3 levels of a project at once:
- UX: wireframing, user flows, interviews
- UI: user interfaces, layouts, visual design
- Dev: design systems, ui templates
Developing a button with a range of props is somewhat isolated from where that button lives and what it looks like, which is again somewhat isolated from what that button does.
One of the custom components I coded from scratch.
We wanted to get moving quickly, so we decided to fork Shopify’s Polaris design system to use as a base. It wasn’t intended to be customised in this way, but it’s an incredibly well-thought-out and well-developed open-source system with a ton of generic components that we could hijack and repurpose.
However, in retrospect, I found the non-generic components of Polaris began to steer the direction of the design. They were so good that they became the “obvious solution” that then removed the need to explore alternate solutions. In later iterations we revisited these instances and designed components specialised to our needs.
Stock Polaris vs. Combine Polaris
Building MVP
Designing and developing
Over the next 9 weeks (I was working part-time, so actually 4.5wks of work) we:
- narrowed down the features we needed for MVP
- developed the workflow users would step through
- customised Polaris to suit our needs, and distinguish ourselves visually
- settled on the information architecture
- built out all of the designs in React (as front-end templates only)
- used the React templates to user test in-the-browser (and on-the-phone)
After that, I moved on to another project, while the devs began work. The design iterated significantly during this time, even though the majority of my attention was elsewhere, because everyone was involved and contributing to the designs. I always encourage this. Often my work is asking the right question to prompt someone else’s right answer.
I love designing in the browser because it’s ultimately what the user will use. The user doesn’t care about the flashy designs that are posted on Dribbble, they care about the end product, and often these two things diverge dramatically. By designing in the browser, it’s more like handcraft—you’re building the thing they’ll get, not just the blueprint.
Plus, it’s just faster than any prototyping tool out there.
Ship it!
The sky and beyond
Propflow isn’t done (is design ever? ha-hah). The intention is to launch the MVP internally within SDI, and use SDI as a test-bed to gather feedback and conduct interviews while using the real product. It’s a godsend being able to build a product alongside the actual users who need it.
Once the MVP is validated internally, Propflow will be released to the wider market.
Feel free to click through the Marvel prototype!