If you’re a Government or corporation creating new policies, regulations, or even laws for COVID-19, rules as code presents a whole bunch of benefits.
Rules are policies, business rules, regulations, and in Government organisations they can be the actual law. Nearly every rule written ends up being interpreted in to systems, websites, apps, or connected devices.
Rules as Code is an approach that acknowledges this, and rather than writing a document which needs human interpretation, creates actual logical rules that other systems can interact with directly (an API). …
Service Design is a strange and inconsistent thing. Few fully understand what the ‘service’ part refers to, and by extension the value in practicing service design gets lost in assumption.
As a result of the confusion our collective practice has experienced, for many people Service Design stopped being about making stuff, and started being about processes and methodologies.
All sorts of newfangled ‘labs’ sprung up. The word innovation was thrown around like dollar bills in a lewd hip hop music video. We’d finally found the panacea for turning those pesky ambiguous problems in to plausible products and services.
Last year I started working on “rules as code” – a government project to draft machine readable laws and policies, rather than just human readable ones.
One of the questions that came up a lot when we discussed creating a computerised version of government rules was “what happens to discretion?”
The answer is simple: nothing.
All that we do when we codify the law is make a version that says whether a scenario definitely does, or definitely does not follow some measurable rules. …
When UX first became a phrase people widely used (15 years ago?) it was a simpler time, and tech-folk had just got in to the hang of testing things with users before committing to massive amounts of development work.
Wireframes became a major part of the digital design process, and as the way we design things started to standardise, the products quickly matured. As an example, Balsamiq, a tool to make sketchy-styled wireframes which were low-fi launched in 2008. …
There’s a bunch of things humans say every day that aren’t actually well defined, but we assume mean the same thing to everyone. That’s an understanding computers just don’t have, because they don’t have common sense like we do.
At the NSW Government, we recently codified our first bit of government rules. That means we made logic statements to replicate the Policy Terms and Conditions a human wrote. You could also codify the rules of a maintenance contract, or countless other things.
But we didn’t create rules using code logic, we interpreted rules that already existed into code logic. …
I’m currently working for the Government of New South Wales where I do a tech design job that I’m fairly certain has no name.
Thanks to a vision of our Digital Gov Exec Director Pia, and the buy-in of our lab director Marina Chiovetti, part of that job now includes an experimental project to create rules (that includes Legislation, Policies, and Regulation) that are machine readable.
We want to to make our rules open to the public to help digital systems to be compliant so that everyone can deliver better outcomes to the people of NSW.
When people make software…
Tech is to digital service design what materials are to furniture, it’s the stuff everything is made of.
Whether you see it, like it, enjoy it, or understand it is irrelevant — data, code, and infrastructure the atoms, molecules, and methods that make a digital service.
The bad news is that digital design is often based on processes, ceremonies, and theory. …
There are always people asking innovators to show them how it’s done. People wanting to ride along for a project to learn the ropes. In more eyebrow raising scenarios there are internal manuals on how to be innovative.
The advice given to those looking for knowledge is usually centred around design thinking, and sometimes even a specific method.
The line between innovation and design thinking is fine, but real. …
Too frequently, we see things labelled as ‘innovation’ — but often, these things don’t work out, the project fails.
But failure is good, right?
Yes! Failure can be good. It’s a great way to learn, but if you’re innovating and your fail overall, you clearly didn’t learn.
So, how do we use failure to help, rather than hinder?
Good failures are the ones you learn from.
Failing is only step two of four, there’s an emotional rollercoaster that comes next, starting with letting go of your idea. I’m sorry, you tried, it was just a bad idea.
So you start…
Designers are like alpacas; confused looking mammals who spit when angry and are covered in messy, often matted, fur.
A little known fact about alpacas and designers is that they are herd animals. Not only do they like the company of their kind, but without a buddy they will actually become depressed, in the case of the alpaca, or apathetic and isolated in the case of a designer.
If you co-locate designers on project teams, pairing designers and creating a micro-community can be a great way to avoid burn-out and apathy. …
RegTech Product guy. Currently NSW Government. Prev: UK Gov, Jaguar Land Rover, Apple & more stuff. Been around the block. Ex digi lecturer. Designers can code!