Weeklog 01 — EpicShot Guide App release
Thinking and doing at Patternworks this week: EpicShot Guide App — design-to-code automation — web apps as malleable systems — dumb agents require better tools — writing is hard.
Patternworks is a product trio who design, build and deliver quality customer interfaces. Sometimes AI is a big part of that, and we’re bullish on it. This is our 1st weeklog where we tune in to a “working/learning in public” tempo.
Three sections this week: working in public > thinking out loud > the curious magpie. Skip ahead as accords your zeal!
Public: EpicShot Guide App release
Last week we released the EpicShot Guide App for AJ Hackett Bungy, New Zealand. We designed the app for one of our trio’s team’s sister company, DWS Cloud. The Epic Guide App is the final addition to the Epic Platform, which DWS have been ideating, designing, building and testing for AJHackett Bungy over the last 3 years.
A guide using the new EpicShot Guide App — part of a system that AJ Hackett Bungy NZ says was installed at a tenth of the cost of its previous set-up, but which can take better photos and video and instantly deliver them to TikTok-generation punters.
— The New Zealand Herald, April 18, 2024
Patternworks designed it in a week and we were able to work through development iterations with DWS Cloud to get it live in less than 4 weeks. Speed of delivery matters!
Read our case study here.
Read the larger context for the app in relation to DWS Cloud’s award-winning platform work for Bungy over the past 3 years here.
Stay tuned for some bigger news about this platform soon!
Thinking: Emerging ways to build web apps faster
We’re bullish on design-to-code automation (eg. Figma for React components) because any time we can increase speed, we “prioritize subtraction and parsimony in the solution space”. Here’s a few concepts and companies we’re actively keeping tabs on in this regard:
Builder.io’s Visual Copilot is on our testing list. Good quick demo here.
Figma obviously sees this as their next step, with recent acquisitions of Diagram and Dynaboard. Their post on hows and whys of Diagram is worth a read.
There are dimensions to this. Prototyping quickly may also mean the low-resolution end as well. For example, the automations and AI integrations that tldraw have been demoing are very interesting to us. “Tab to accept suggestion”.
With a design system in place (and the integration code to render it), the low-res sketch can be converted to a working demo instantly. Here’s an example.
That doesn’t mean it’s production ready, but certainly cuts out a huge amount of work.
The last 20% will be difficult, as ever: “For now, it’s just an experiment. It would need more feasibility testing before it got added to a product roadmap or strategy.”
The gains will be yielded by those develop the process knowledge themselves. Now is the time to experiment!
Overall, less time spent on converting design to working code means more time spent thinking bigger about design.
If design is taken seriously—beyond graphics, beyond the interface—then this extra design time should naturally lead to “the next largest context”. Anything that allows one to climb up this ladder of abstraction will be climbing up toward new value.
So the real title for this section is “emerging ways to spend more time designing”.
Curious magpies
Half-baked proto-insights for curious magpies like us.
Root-level bullet point is the collected source, nested-level is our comment.
Alex Komoroske on how malleable systems can be made out of rigid building blocks.
If you have the agency to mix and match rigid building blocks, then you can assemble a malleable combination.
The AI systems savvy (if indeed that’s your game) won’t get you far without knowing how to create web apps from thoughtfully constructed components.
This is true even if you don’t have agency over the individual pixel-perfect / rigid building blocks.
In essence, pixel-perfection is the least of worries when experimentation is the first-order concern.
In a given system, when you cannot compose the building blocks, your agency is reduced.
Sounds like a given. The through-line for this is that your means to experiment is dependent upon having a team that can deliver web apps.
The larger the building blocks on a relative basis, the less agency you have as a user. […] Apps are like big duplo blocks; hard to combine in any but the most rudimentary of ways.
How good is your web app team at building the building blocks?
Malleable software will have components that feel like sand: rigid building blocks, but so small that the overall thing flows like a fluid.
Think in component primitives! Isolated from dependencies yet systematised in relation to other components as a whole.
@Ate-A-Pi interviews by Hrishi Olickel, co-founder of Greywing, a copilot to master maritime data with AI, about integrating AI systems into their product. The twitter summary is high yield and very “of the moment”.
On the surprising thing users most commonly ask the AI, “Most initial questions are meta - 'How do I use you?', not the task the system is for.”
Designing UI that counters this is so important to clear the way for intended thing you spent so much time and effort on: the AI system itself.
“…to a user, the system is thinking.”
It’s not. That’s just how long it takes to send the input to the servers and back. But that doesn’t mean we should not give users what they need to feel comfortable! HTML streaming—transmitting data as it's created such that the words stream into the UI—is a great hack for this illusion.
On how enterprises are like sleeping AIs waking up “Very high value technical expertise inside of a company can now be baked into systems because they already have the documentation”
How do you currently expose the company knowledge your customers want? Hoist your thinking to “datalake” concepts and
On the need for models that companies can control fully in terms of access to data “The next big jump for open source is going to be when these models get embedded client side.”
The clock ticks. We wait.
On how LLMs require less intelligence when connected to data rich enterprise systems “Agents can be dumber if your tools are better”
This requires malleable systems! See prior section.
Writing is hard and time spent on it is always underestimated. It’s the usual story: if you’re not feeling guilty about how long it takes, you either brilliant at it (your call), or you’re probably not spending enough time on it.
We’re in the second bucket: always revising our website’s value proposition, especially as we discover what our skillset means to new clients. And “Writing copy for landing pages” by Stripe is an outstanding kickstarter for just that job:
“common missteps that I see: landing pages prioritise the story of the startup rather than the journey of the customer with the startup.”
That is, address it your customers.
Quick wins:
Focus copy on them: start with “you”.
Defang objections with an “even if” clause.
Limit each sentence to one idea.
Create a landing page that’s not your homepage. A landing page speaks to visitors looking for something specific, features content relevant to that particular item, and contains a specific CTA. Your home page might not be so specific.
Add pattern, texture, and shine to a block of copy. But perhaps avoid the word “delve” for a while.
Don’t overthink where you should start. Just get started.
And then keep drafting.