Define Personas for Home Assistant?

[BoneheadFraggle]

Why Personas?

Steve Jobs gave this advice at the Apple WWDC in 1997:
"You’ve got to start with the customer experience and work backward for the technology."

I often find myself discussing Frontend features with people that use HA in a totally different way than I do. While that is enlightning, it can also be frustrating.

Why frustrating? My perception is that when it comes to the HA team's decisions and Frontend changes, many of the contributors and those imvolved in the discussions are very technical, and maybe a bit too often very similar in their view of what is a good feature. I think this may impede development of usability and the streamlining experience approach. It seems like there is a lot of focus how to get HA to be easier for new "users", where a "user" is a person who setup HA. I see less improvements and maybe even a few deteriorations for "consumers", meaning users that don't know a thing about HA, but just want to turn on the lights or put on some music. An example of this is the new re-arranging of control panel. I don't mind it at all, but it is only relevant for the first defenition of a "user". A "consumer" won't ever notice it since they can't/shouldn't use it.

If not already done, I therefore suggest that the Frontend team define a few Personas and try new features on those before implementing them into HA. My defenition of Persona is "A persona is a semi-fictional representative of your ideal user".

Examples of Personas:

1. Adam. Non-technical user. Knows no programming. Can not decribe the difference between an entity and a device and is not really intererested. Previously used Smarthings, but have become more reluctant to use cloud services and aims to go local. Found HA by recommendation. Adam is the only user of HA.

2. Bea. Bea bought in to the concept of "Home Assistant" and now everything in Bea's household in handled by HA in one way or the other. There are several wallpanels to control household electronics, lights, display graphs, music, and infrastructure.
   Bea's partner, kids, and house guests use those panels for all kinds of daily tasks. Usability and intuitiveness is key, as well as only letting HA-consumers see and interact with selected dashboards.

3. Caesar. A programmer that often contribute to HA code. Probably beta or even dev-user. Understand the architecture, know quite a bit of programming. The only user in the HA instance. Not that in to GUI and UX. Looks doesn't really matter since everything is best handled in code anyway. Active in HA Discord Support groups.

Is it really necessary?
A recent example is the introduction of the new, mandatory, search function where any user can access all entities - even those not visible in any of the dashboards presented to the said user.

• For users like Adam (as described above) that is a great feature - finally it even easier to find correct entity.
• For Ceasar, it doesn't really matter, since YAML and Python is the only tools of choice.
• But for Bea, that's a definite no-no. Suddenly any guest in the household could access the house's heating system, personal data like other phone messages or even turn off the entire household's water supply and electrical main switches or activate the alarm.

More examples?
Let's compare a user experience in HA to being a passenger in a car.
As a passenger, you are presented with a lot of stuff like climate control, navigation, and music players.
But if you have been a passenger in a Volvo or Toyota, you will find your way in a Tesla or Audi as well.
And most important for this comparison, in a car you are only presented with selected bits of data and controls. Most of the data and settings are hidden from you until you enter the super hidden service mode (which most passengers don't).

That's the way I like to see typical "consumer" of HA. If you know how to browse the web in general, you should be able to use HA dashboards as well. But you shouldn't be able to accidentally turn off the fuel pump or activate the electrical sunroof unless the car manufacturer/HA dashboard editor wanted you to.

I want to stress that we don't want to confuse those Personas or desire to hide things with technical access or security, which I realise is a much more difficult aspect. "Bea" only addresses the user experience and "perceived access" to HA.

What are your thoughts on this?

(Sorry for any bad wording. Please keep in mind that if anything seems rude, that was not my intention.)

[zsarnett]

@matthiasdebaat Has been putting together Personas

https://design.home-assistant.io/#user-test/user-types

Not sure the Bea user makes sense here... It's mixing two types of users IMO. New User and Technical Admin.

[BoneheadFraggle]

Well, Bea is me :-)
I am the administrator and the creator of all dashboards, but I use the system as an ordinary consumer to make sure everything is working smoothly for the others.

The examples are just three examples, I'm sure there are a lot more.
But I agree, it makes sense to spilt her up in two types.

I am glad that the perspective is already there, thanks for the link.