Good lord I could've really used this a few months ago when I was butting heads with product management insisting on building things first rather than prototyping. This might have helped communicate the complexities that I feel were being glossed over, in a way that was approachable to non-programmers and non-designers.
Definitely giving this a go, thanks for sharing!
One thing that tripped me up was the name. I use Sketch[1] quite a lot and the reason I clicked the headline was I immediately though maybe this was something new around implementing design systems using Sketch. This tool is much more interesting to me, but still, thought I should mention it.
Loving the simplicity of the design in this little tool. It'll be interesting to see whether it works beyond simple experiences. The syntax makes me think it ought to be composable, like having larger state charts composed of smaller components, pluggable via open ended transitions either by omitting the target state or having some special syntax saying "plug in your state here".
Anyway, definitely going to give this a go, looks great!
Wow. You really are not kidding. What a mess. I actually feel stressed looking at their home page. It's overwhelming. THEN they've decided to top the chaos off with animated Figma-cursors that have no apparent relationship to the hero content.
It doesn't get any better as you scroll either. Everything is animated and changes while you're trying to read it.
I tried to give them feedback through there "Contact Us" form and it's broken.
-----
Sketch. If you read this thread, please take this feedback seriously. It's shocking how unusable your marketing website is.
I thought it couldn't get worse until I tried to select text on the front cover and realized the whole thing is draggable. The designs on the side are draggable as well, but they're also images and it conflicts with normal image dragging on Firefox
This would be useful for more systems than just graphical user interfaces and frontend development.
Backend systems, distributed systems, stateful protocols and microservices are complicated and hard to think about. Raft for example.
I am working on a state machine formulation that is text based and I have an idea which I think would prevent entire classes of bugs.
The idea is that we can see the state machine as a graph and check reachability of states between state machines. If the code literally never fires the event that would cause the reachability of the next state, that's a bug.
The number of times I've been writing some code that uses threads or distributed systems and there is absence of behaviour, it's tricky to debug absence of behaviour.
I've always wanted to "see the future" from my IDE to see what state my code puts everything in.
One of my ideas is the idea of value flow tracing to detect steady state systems, systems that always make forward progress.
I prototyped this using computational tree logic (CTL). You can express the non existence of trap states and reachability of all states quite nicely and fully explore the state space symbolically. The drawback is you can't really do numbers in it.
It's similar to Shape Up's Breadboarding[1] in its simplicity and UI/UX orientation, but unlike the former, it's based on a formal Harel Statecharts[2].
Added bonus, it can be formally verified using Alloy [8].
Another similar FSM-based UI/UX tools are XState[3], XState Visualizer[4], and Stately.ai[5] powered by XState.
But Sketch.systems seems to be easier for fast prototyping using plain text format (what they mistakenly calling "markdown"). While XState generates a JS code, which can be used in React apps.
I guess it's possible to convert Sketch.systems format into XState, or other similar ones, after finishing prototyping and moving to implementation/debugging.
Sketch.systems seems to be much more lightweight, which is important for fast prototyping, and lowering barrier to entry for non-tech people.
Another relevant method is Event Modeling[6], which is somewhat in the middle between Breadboading and EventStorming[7]. Its main advantage is that checks the Information Completeness of the entire flow (both frontend and backend, including external services/systems, not just UI/UX), and that it can map 1:1 to CQRS/ES software design.
My hope is that XState can become nearly as easy to use for visual/poc prototyping, but you’re right. They’re not quite the same tools and XState is more complex.
The team has awesome plans for the visualizer and V5 is around the corner which simplifies and generally improves the system overall, hopefully making it easier to learn but also to improve the visualizer.
This is a very interesting take on "how can we test/poc a given component. I would be great to see a demo for a full application given this can help system designers build complex systems and track what activities are needed. Looking at the iPhone lock screen example [1], this is very useful. you can see that this is not aiming to do the UI render of the actual components, more about plugging in other resources like images.
I might try this, to see if it immediately solves a problem of helping think through interfaces and workflows. Looks promising, but these kinds of tools can get complicated quickly.
We built https://www.teampando.com out of a similar love for state-based thinking. We turn natural language requirements into state machines, have a Figma plugin to connect designs to states (didn't realize sketch.systems had embeds that can support that - very cool!), and can export XState state charts.
State-based thinking is already helpful just to get your thoughts organized as you're building something but it's super helpful to give everyone (eng and non-eng) on the team something concrete to talk about and play with.
The other articles [1] go more into this, but it includes ideas about auto-generating flow-charts, easily export your UX source code, generate working front-end, etc.
I once presented this to ~30 UX designers, and they liked the general idea of a more holistic UX tool that does not take the wireframe as the central piece, but the project as a whole. But when I started showing text-commands as a prototype to show how different interfaces could be built for ux source code, I got nothing but blank stares.. haha, they did not want to look at text representing elements.
So while I agree with Sketch that there is value in UX source code, and the tools they have created seem great. I hope they integrate it in their other tools, so you can output the same source code via a GUI.
And then someone could write a script that converts my UX source code, from my mobile wireframing app TinyUX [2] with theirs :D.
While there is some overlap, the article(s) are not about just wireframes, but also a tool for the full UX project, so this includes customer journeys, stakeholders, feedback notes, etc.
The goal would be to figure out a way to capture and manage UX projects in a way that you are not bound by a single tool. So you can import/export parts to other tools in your chain.
I know you were being tongue in cheek, but I am pretty sure this launched right around 2017. In fact, I don't think it's been updated since. I always thought this was a really great idea, but I admit it is strange seeing it crop up again now (looking exactly as it did years ago).
It's funny though because we used to protect our whiteboard sketches from other teams even. And now this company wants us not only to replace something as simple as a whiteboard sketch, but to put it in their database.
As someone who dabbles in both design and development, this is so close to web development that I can't immediately see where it would be useful to me. If I have to write React anyways, why not just build a small prototype?
The video positions this as a tool for designing around edge-cases and offloading work from the developer to the designer, but to me, the main difficulty in development are the edge-cases: "What are the possible errors that can occur when I call this API?", "What would be the most fitting design for the realities of our architecture?" It's as much the developer's job to solve them as it is the designer's.
The example, "What happens if the user backgrounds the app?", is a question that inherently must be solved through back-and-forth between the developer and the designer, because the designer might not understand the realities of the operating system (see iOS multitasking). It's easy to point to loading states or network errors as example edge cases, because they're well-known. But usually, the developer will be the first to discover such problems.
One of the developers here. Sketch.systems is about 5 years old and we haven't actively worked on since its release––but it's still used fairly regularly by folks and does the job it set out to do! If anything ever seems broken, reach out (our Twitter accounts are in the website footer) and we'll definitely take a look.
I try to mistake actively developed on for needs active development.
Some of the tools I like haven’t significantly changed for me in years. There sometimes is a “good enough” to software that I don’t need a developer to work on it endlessly for the rest of their life.
But I will say that my interest in this, it was dashed after your comment. This looks like a tool is complex enough to probably not be perfect.
Getting new users to learn that syntax seems problematic but presumably a NLP interface between that syntax with a big language model would be straight forward to whip up?
As a writer of embedded software I'm a big fan of state machines. I always thought they were underused in other domains, so it's good to see things like this.
Paraphrasing I-don't-know-who: State machines are not optional. The only difference is whether you're going to have an explicit one, or a crappy, accidental one.
> Isn't there already a tool that has "Sketch" in the name?
> Yes, there are many!
So the justification for confusingly reusing the name of an existing product in the same space is just "there exists many other products with the same name"? Is it just me or does this not make any sense?
I do love the idea of exploring behavior, though I remember checking this site out a couple years ago and didn't quite understand the state machine language they were introducing. I should give it another shot though because it seems like it could be super useful.
I'm free of this pain currently but I could see this saving a huge time pain in the product -> engineering handover step. Very cleanly done. Honestly great just for making sure engineering designs have covered all paths.
I'm sorry but I have to ask: did you search the word "Sketch" online, visit sketch.com, and then just think "YOLO!" and name your thing Sketch.systems for inexplicable reasons?
Definitely giving this a go, thanks for sharing!
One thing that tripped me up was the name. I use Sketch[1] quite a lot and the reason I clicked the headline was I immediately though maybe this was something new around implementing design systems using Sketch. This tool is much more interesting to me, but still, thought I should mention it.
Loving the simplicity of the design in this little tool. It'll be interesting to see whether it works beyond simple experiences. The syntax makes me think it ought to be composable, like having larger state charts composed of smaller components, pluggable via open ended transitions either by omitting the target state or having some special syntax saying "plug in your state here".
Anyway, definitely going to give this a go, looks great!
--
[1]: https://www.sketch.com/