A UX Designer, Solutions Architect, and the Root of All Cool Things
Aron joined Castle’s SF team as a Solutions Architect the first week of March. As a core part of his role, he’d become one of the experts on Castle’s product. From the use cases we solve to integration edge cases, he’d learn it not just for his own sake, but so that he could propagate the knowledge onto others. For both internal and external audiences, he’d condense and re-shape this predominantly technical information through a series of pre-sales demos, webinars, and trainings. And on his first day, we closed the office.
An onboarding that was intended to include a series of in-person whiteboard sessions was immediately derailed by a thing called Covid. Many of us who have worked in technical roles are familiar with these sessions. The collaborative process of mapping out a product’s architecture, zooming in and out on the fly, as all of the pieces to the puzzle fall into place.
Whiteboarding without a whiteboard
Even if you’re not directly familiar with the C4 Model for visualizing software architecture, if you’ve worked in or around technical products, you’ve most likely participated in or even presented a session that resembles something pretty close to it. These whiteboard sessions are an incredibly fundamental, low-friction technique for getting our technical ideas out. Funny thing about whiteboard sessions though – they’re a lot easier to do in person.
For Aron’s onboarding, we scraped together a series of new slides. Each one attempting to map to the same narrative we would have done on the whiteboard. Each click of the mouse presenting the next slide, zooming in to focus on the next layer of the stack. Each slide tediously re-drawn from scratch. But new questions lead to new tangents, which in turn require new slides. As we all did in those first days of quarantine, we just pushed through and got it done.
Customization at scale
Now it was Aron’s turn. Within his first month, he was leading technical presentations for a variety of audiences, each more or less technically savvy than the next. Many times it was during pre-sales or customer calls. At Castle, we provide a very hands on, consultative experience for many of our customers, where we dive into the details of their own stack layer by layer and craft an solutions that perfectly fit their technical and business needs. Each app and business is different though, so a “one-size-fits-all” playbook isn’t great in this situation. We need the ability to adapt rapidly, and shift from one call to the next with speed.
As Aron recalls, “I went through some cycles, starting with a sales deck that only had one technical diagram in there.” He quickly recognized the need to separate the steps. “I wanted something dedicated to our Cloudflare integration. Cloudflare sits at the edge, not behind the application, so there are slightly different details. It’s Important to distinguish the two.”
You only have so much time with an audience. When you’re trying to cover a lot of ground, it’s important for people to be able to build a mental model, to keep all the pieces in their heads.
Visual modeling for visual learners
Previously in his career, Aron had run into a similar tricky problem. His internal teams were working with 20 different components. “It was difficult to explain to other engineers through a series of tickets, slack threads, and wikis how they were all connected. So I created a diagram. Very quickly everyone grasped it. Then the entire team started using diagrams.”
These were for internal use, inspired by Unified Modeling Language (UML) – a visual programming language, useful for showing the interaction of different components and elements. Pairing UML with the C4 Model, you can really start to bring architecture to life. It’s almost like Google Maps where you can see the globe and zoom all the way down into the street view. But in this case, you start with infrastructure, then show components, then the code, finally seeing how the actual functions are interacting with one another. With that framework, you can give the audience a sense of how deep you’re going.
Could we do something similar for external audiences?
Architecture Icon Sets
This isn’t an entirely new concept. AWS, for example, has done a great job in preparing a user-facing set of AWS Architecture Icons that does just that. Aron, who holds an ever-growing set of AWS Certifications, mentioned “I loved how they had come up with a visual language for their own systems. It gives architects a quick way to get out their ideas with how their workload is going to be structured.”
From a UX perspective, having a theme of repeated patterns that the audience can visually grasp helps them build these mental models faster than writing it in long form. It’s a language that hits them emotionally and conceptually. Something as simple as a check mark can symbolize that something affirmative or positive is happening.
Applying UX to architecture
Aron pinged Jin, our lead designer, asking if they could setup a 1:1. That first session became focused around this topic. During that first 30 min call, Jin dug deeper into Aron’s role, trying to get to know more about his responsibilities and his work style. “Out of that, we both identified tools, practices, processes we are using to help with our job. I proposed we use Figma to create these architectural diagrams”, Jin recalls.
Jin’s goal was to figure out a way to unblock Aron, while providing a process and tool to help with scale. Jin noted, “I wouldn’t have the capacity to provide one-off illustrations. So Aron needed to be autonomous to put his ideas on paper quickly and efficiently.”
Given the flexible nature of Figma, Jin was able to easily to create small components that were highly dynamic and interchangeable. He designed them in a way where Aron could replace any icon with the Font Awesome icon set. He could also replace any text labels. Or draw any arrows to cover any space. He could resize and move things around as needed.
Simple and modular solutions
Within 30 minutes, Jin had the first Castle Architectural Icon Set ready. He sent the project to Aron, along with some examples as a starting point. He highlighted how the mini components & modules could come together in a great way. He outlined the intentions behind certain details – for example, how the really thick arrows indicate lots of traffic, whereas the thin arrows show individual requests. “Once Aron knows the language, he can run with it”, Jin imagined. And run with it he did.
Within 3 months, Aron has hosted over 50 presentations. 95% are technical in nature, and mostly in group settings. Each stakeholder has different needs. Security engineers, network devs, project managers, all needing to see different things.
New diagrams are whipped up by Aron as needed. Some diagrams show the integration, where it sits. Others focus on use cases – what is logically happening. Others compare and contrast “before-and-after” scenarios (i.e. default settings vs custom configs).
According to Aron, “the diagrams help with explaining processes. Showing current pains vs a new, simplified process. There’s a tremendous difference from before to after using them. Especially with repeated questions.” Before the diagrams, Aron recalled a near certainty that the same question would be asked twice on a single call – notably when it came to the integration, and where a given piece of logic would sit with regards to a prospect’s application. “After the diagrams – each question became unique, and additive to what had been presented. It leads to a much more productive conversation.”
Unexpected ROI
I asked Aron to describe how he’d feel if Jin’s architectural icon set suddenly disappeared tomorrow. “Sadness. Dismay. Jinnnn!”
As recently as this month, Aron has used Jin’s architectural icon set multiple times. “I was planning for a webinar, I knew it was there, so I jumped right into it to add a few new diagrams. And last week, for a new deal, we’re creating an integration set custom for them, with their logo.”
After originally handing the icon set off to Aron, Jin didn’t actually know how widely it was being used. After coming to learn about this, he remarked, “I love that there’s scalable value of work that took only 1 hour to deliver. That’s tremendous ROI. Hearing this, I’m looking forward to my commission’s check!”
Aron’s affirms, “this icon set has lasting, lasting value – even if there are weeks in between I’m not using it. It’s the root of all cool things.”
Tips for cross-team collaboration
Being a product led, fast-moving startup, adaptability and speed to execution are essential to our success. So much of this relies on cross-collaboration towards common goals. In looking back at this story, we noticed some key insights that are repeatable, and might help others when it comes to establishing a culture that enables quick execution on cross-team collaborative efforts:
- Break down the barriers between teams. Create the opportunities to cross collaboration. Especially if you put energy into hiring top talent, provide an environment where each individual can inspire and positively influence one another. At Castle, we encourage frequent 1:1s with anyone in the company, even if it’s just a 30min chat to get to know one another.
- Use what you got and keep it simple. It’s easy for ideas to blow up into major projects that get stuck in prioritization backlogs. Look for quick wins, and use the tools and skills that are already at your disposal.
- Put yourself in their shoes whenever you’re trying to help a teammate. Spend a few minutes getting to know their role and responsibility, the processes and tools they use, and the root of the challenge they are trying to solve. A few minutes understanding a different role can be very eye opening, both highlighting unexpected challenges, but also new opportunities for collaboration, efficiencies, and alignment.
- Look for examples of how others have solved it. Rarely do we stumble upon a truly unique problem. Spend some time searching for inspiration or ask others how they’ve solved a similar problem in the past.
- Build modular tool sets that allow others to use them in flexible ways. This can prevent bottlenecks and create lasting value. It also allows you to ship a minimal solution quickly, and add to it over time.
- Record a demonstration of the finished product along with examples, guides, or templates where possible. Building the greatest solution in the world doesn’t help if others don’t know how to use it. Spend that extra hour to prep some samples and trainings to help others get started.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Brian Feldman. Read the original post at: https://blog.castle.io/a-ux-designer-solutions-architect-and-the-root-of-all-cool-things/
