Last week we were honoured to win the Samantha Hunnisett Access Award at the CM Awards.

To be honest, I wasn’t expecting it. Most of my attention was on the big-ticket award of the evening — the Lifetime Achievement Award for Alli Gaskin. Alli was an awesome SLT colleague and friend, and she will be deeply missed. (If I did have any clue we were up for it I might have prepared a coherent speech and not drank two bottles of wine before hand. Apologies to all those who heard my garble on)

But fittingly, Alli also had a direct connection to Echo. While working at Lancasterian she supported a child whose communication needs weren’t being met by any existing AAC system. Echo bridged that gap. She immediately recognised its value and became one of its strongest champions. That connection made winning the award all the more meaningful.

Where It Started

Echo itself began initally as “Pasco”. Named by Euan Robertson (Phrase Auditory Scanning Communicator) we had it drafted for a while as we had around 6 or 7 end users who simply weren’t being supported by the auditory scanning options available. But then one of our clients Paul Pickford one day reached out to us. Paul said:

“I’m selling some stuff and I want to donate some money.”

Paul’s donation gave us the chance to act. Using our RICE framework, we prioritised building this tool — knowing it could have a meaningful impact.

The first version was hacked together quickly, but it worked. People like Darren, recovering from a brain stem stroke, were among the first to try it. From the start, Pasco (and then Echo) was shaped directly by the people who needed it.

A Chinese ICU Case

One case that has always stayed with me came from the early days, when Echo was still called Pasco and lived as a web app.

I met a woman in intensive care with significant visual impairment and minimal movement. But the bigger barrier? She was a native Chinese speaker, surrounded by English-speaking staff. Translation tools let staff tell her what was happening, but she had no way to respond.

We added multilingual support into Pasco: staff could cue in English, but she could output in Chinese. For the first time, she could communicate back. Her parents — also Chinese-only speakers — were in tears. I tried explaining with Google Translate, but it butchered my speech so badly I gave up and just demoed it. Seeing her finally communicate was enough to make me realise it was worth it.

Pasco Becomes Echo

At that stage, Pasco was still rough around the edges. The two-switch scanning had bugs that were difficult to fix. That’s when Gavin Henderson rewrote it in SwiftUI. (Side note: SwiftUI is a dream. I love it.)

That rewrite became Echo.

And then something amazing happened. I was at a conference in Croatia, getting ready to speak, when I noticed a talk being given in another language. I couldn’t follow the words at first, but eventually I realised what was being demonstrated on screen: Pasco. Somehow, it had been picked up and shared across borders, because we had made it open and multilingual. That moment drove home how far-reaching these tools can become when you don’t lock them away.

Open Source and Ongoing Challenges

Echo has always been about more than one app. It’s about showing what’s possible — and letting others build on it. That’s why we’ve kept it open source: 👉 github.com/acecentre…

We’ve also learned when to change direction. For example, we once had a clever “auditory splitting” feature — playing different parts of the audio to different devices. It worked, but it was fiddly. And ultimately, Apple’s iOS audio system won’t let us split audio streams the way we need. Until that changes, it’s not practical.

But the point remains: innovation often starts with finding a solution for one person. When shared openly, those solutions ripple outward and benefit many.

A Team Effort

So yes, the Access Award has Echo’s name on it. But really, it belongs to: • Paul Pickford — whose donation started it all. • Hossein Zoda — who built the first version (Pasco). • Gavin Henderson — who rewrote it in SwiftUI and brought Echo to life. • Michael Ritson (Ace Centre) — for deep input on visual impairment and access aspects. • Charlie Danger — who once needed it working with a scroll wheel as input. • And most of all, the end users — Darren, the client in ICU, and many others whose needs shaped the app.

It’s also for the wider Ace Centre team, who foster and curate ideas like this every day by working closely with individuals with disabilities.

So sometimes.. just sometimes.. a couple of months works pays off. Or I guess we could frame this post around successful product development - keeping the end user the focus of your development and involving them at all stages of your development cycle is key. We are proud to shout loudly about this.

So two months ago we saw Judith. Technology has not been successful for her before. (You can read more why in my previous posts). So we rapidly developed a SwiftUI app that was unique in its operation - you dragged from one letter to the next. Trying it with Judith we still had a problem - positional errors and missing letters were high. So we then rapidly worked on a “correct-a-sentence system” and settled on using a Azure OpenAI API (GPT3.5) and then developed our own custom model alongside this (needing something that worked offline and privacy first was key (NB: The videos is this offline model - Not GPT). A few iterations of this and its correcting as good as GPT 3.5 83% of the time.

So two months later, what does this all mean for the end user? They can now write on technolgy to communicate for the very first time. Happy - well so far yes. But long term AAC use is complex and not just down to the technology. So lets be curious and proud at the same time. There is more to do

• Small tweaks in the UI
• Its correcting a bit too much at times - sometimes adding more grammar changes than I would like - and equally dangerous - losing words. To fix this we could further train our custom model.

and then more I’m sure the next time we review this cycle of the iterative development cycle.

What does this process look like overall?

We follow the double-diamond development cycle. It’s a pretty common approach yet following it is not always easy.

So lessons so far?

• Iterate Fast: Rapid prototyping and adjustments are key to finding viable solutions for complex, unique solutions. There is a much longer tail to development for solid, reliable products but getting somewhere fast helps to see whats important.
• User-Centric Design: Keeping the user at the heart of all stages of development ensures that the technology we develop truly meets their needs. Its not always easy but it can be done. Its important to do this as part of a team though. It can so easily be lost as to whether you are getting carried away or whether you are on track. We pride ourselves on at Ace Centre being a transdisciplinary team where never one person sees the whole picture.
• Continuous Learning: Every challenge presents a learning opportunity, pushing us to constantly improve. And heck - its good fun too seeing big gains.
• Passion and Persistence: A keen interest in making a difference and the drive to keep pushing forward are indispensable.

Objectified (2009, 75 minutes) is a documentary film about our complex relationship with manufactured objects and, by extension, the people who design them. What can we learn about who we are, and who we want to be, from the objects with which we surround ourselves?

It’s a great film (and free to watch from March 14-17!) but in particular, I love this quote from Dan Formosa, Design & Research, Smart Design, New York (around 6 minutes in)

But really our common interest is in understanding people and what their needs are. So if you start to think, well really, what these guys do as consultants is focus on people, then it’s easy to think about what’s needed design wise in the kitchen, or in the hospital, or in the car.

We have clients coming to us and saying here’s our average customer. For instance, she’s female, she’s 34 years old, she has 2.3 kids.

And we listen politely and say, well that’s great, but we don’t care about that person. What we really need to do to design is look at the extremes, the weakest, or the person with arthritis, or the athlete, or the strongest, or the fastest person. Because if we understand what the extremes are, the middle will take care of itself.

View it online at www.ohyouprettythings.com/free

Some clients we see are fantastic with paper-based solutions. But sometimes, finding powered AAC systems which give them more independence is far trickier than you may think. Consider Judith. She doesn’t lift her finger from the paper. This continuous movement is surprisingly not well supported in AAC. Your obvious thoughts are SwiftKey and Swype, but they require a lift-up at the end of a word or somewhere else. Next up, you may try a Keguard or TouchGuide. But then, for some users, this is too much of a change in user interaction. Even if you succeed, you often ask an end user to change the orientation or layout of their paper-based system.. and all in all, it’s just too much change. Abandonment is likely. The paper-based system is just more reliable.

So what do we do? We could look at a bespoke system. But typically, it requires much thought, effort and scoping. That’s still needed, but you can draft something up far quicker these days using ChatGPT. It wrote the whole app after a 2-hour stint of prompt writing. Thats awesome. (Thanks also to Gavin, who tidied up the loose ends). So, this app can be operated by detecting a change in angular direction or detecting a small dwell on each letter. We need to now trial this with our end user and see what’s more likely to work and what’s not and work this up. We may need a way of writing without going to space (something that we see quite a lot), and I can see us implementing a really needed feature, autocorrect. This is all achievable. But for now, we have a working solution to trial a 500 lines of code app made in less than a day’s work.

At MOSI in Manchester today, I saw Stephen Hawking’s Chair and other neat things from his office in Cambridge. Note the spaghetti of cables. It’s tricky to figure out where all the leads go, but I’ll give it a wild guess. The plugs look like either mini XLR or the old PS2 Serial leads. Some questions, though; I’m unsure what the “Filter” box fits to and why is the Words+ box even used? I thought the connection with Intel meant he was using ACAT. Why is that Words+ Softkey box the parallel version when there is clearly a lot of USB kicking about, too? Why are we plugging into something behind the chair when surely the tablet has the speakers anyway? There are as many questions than answers.

• Words+ Archive page (This is the USB version of the softkey box)
• Case for Original Synthesiser made by David Mason at Cambridge Adaptive
• Chair details

Last week, I visited a client for work to test out a sound switch device. For one reason and another, the kit didn’t pan out on the day (NB: Highly possible it might have been me.. I need to try again). But with the recordings we got, we can now do some fun work and create a melspectogram correlation technique. It might work.. It certainly looks pretty reliable against background noise and talking. You can see our work in progress and try it yourself at github.com/acecentre…