This version of the Speechly documentation is no longer actively maintained. For up-to-date documentation, see the latest version.

Speechly Design Philosophy

How Speechly should be used to improve your application’s user experience?

Speechly is solving voice in a completely novel way. Our API is fully streaming to enable a few key concepts that we think are the missing piece in voice. We have put together a number of best practices that are worth considering when developing your application.

They are split into four short “chapters”, with the following content:

Chapter 1: Setting the right Context

  • Don’t build a Voice Assistant
  • Design for Command & Control
  • Give visual guidance on what the user can say
  • Use voice ONLY for the tasks it’s good for

Chapter 2: Receiving Commands from the User

  • Onboard the user
  • Avoid using a wake word
  • Use a Push-to-Talk button
  • Signal clearly when the microphone button is pushed down

Chapter 3: Giving Feedback to the User

  • Use non-interruptive modalities for feedback
  • Minimize latency with Spoken Language Understanding
  • Steer user’s gaze and minimize visual unrest

Chapter 4: Recovering from Mistakes

  • Show the transcript
  • Produce results fast, but offer opportunity to correct
  • Have an intent for verbal corrections
  • Offer alternative ways to complete tasks without Voice

Last updated by Ari Nykänen on June 17, 2022 at 13:50 +0300

Found an error on our documentation? Please file an issue or make a pull request