Holy SSH, I.T.

Getting to know the problem

I broke down the technical needs — multiple security keys, education around what a security key even is, and some sort of information confirming you set it up right — and designed a simple interaction flow using existing patterns that allowed for someone to quickly add a key via form inputs.

SSH customer journey

Where should this thing go?

This feature is not for everyone. It's advanced, and since this was a first-stab at a feature, we wanted to avoid a bunch of support influx from people messing up their sites that didn't know what they were doing. We didn't have time for full research here, so I looked for the least risky location.

Being that this feature requires personal security keys, it made the most sense to put it in the account where we store other things people don't touch that often — passwords, two-factor authentication, etc. Later usability testing proved this was the right call.

Testing quick, detailed wireframes confirmed content structure + context early

The day-to-day

In the context of the day-to-day we know that our users are using SSH with a specific site. So we added some context at the site level, as well.

I added the specific login information for each site on our "advanced" tab. This is a place we commonly put quick actions and more technical features for those that actually know what they’re doing. Early usability testing was promising! The feature is in the wild and we've seen people using it, and no meaningful increase in support tickets around it.

Project impact + reflection

I loved this project because of it's complexity. I am not a developer, so it's fun to really dig into the use cases and requirements on things slightly above my head. If I can make the feature easy enough for me to use it, it generally means we're on the right track 😂.

I am excited for the next phase of this project — working inside of the actual terminal interface. I have a dream to make it feel more like a text-based ARG than hacking the gibson.