I hesitated to share this post here because it's more about UX than really teaching something new about software development. I thought it'd still be relevant as we're all building experiences at the end of the day.
At Squadlytics we have a strong commitment to simplicity. Heck, I'll go further and say that this is our raison d'être, and we've put a little framework together to help measure friction in our product.
Wait, what's Squadlytics?
Our platform helps teams stay focused by providing continuous feedback on goals and results. Most of the teams we talk to have goals they care deeply about. They worked hard to figure out the best path forward, and they strive to deliver their best work.
But as they grow it becomes difficult to share progress and get visibility on how people are doing. You're either using a spreadsheet, which gets lost among all the other docs of the company. Or you have to set up heavy-handed performance management systems, which can be complicated to use and slow the feedback loop.
We believe we can make our users happier with a simple, lightweight solution. We want to help teams know what the priorities are, and how they're progressing. Then we get out of the way.
How we treat simplicity as a feature
Defining a framework to measure simplicity
When you release a new capability, it's reasonably easy to measure its success. You look at the analytics events and compare that with your expectations. It's straightforward to measure the impact of things that are added to a product.
But when you talk about simplifying things, removing behaviors, it's hard to understand how much you're moving the needle because we lack metrics for that. It's much easier for us to quantify outcomes (how many users signed up) than processes (how much effort did it take for the user to sign up).
Rather than coming up with a complicated formula, we decided to look at 2 things in our case:
- How many clicks does it take to complete a step?
- How many times do you switch context?
We then weighted both actions and decided that a context-switch would be 3 times as painful as a click. This is purely arbitrary and could be debated, but the goal was to reflect that having to go from one screen to another is much more annoying than clicking around the same page. So we end up with this:
Friction Index = Clicks + 3 x Context-switches
Defining the user flow
Once we had the framework, we had to pick a user flow to measure. We did not want to stop at the bare minimum after signing up. Repeating some core actions would give us a better understanding of what our users go through.
If you stop at one instance of each action, you can easily be under the illusion that your process is good enough. But if creating a page takes a dozen clicks, it will quickly become a pain if it's a task performed often in your product.
So our scenario was the following:
- A user (you) wants to sign up for Squadlytics to give it a try with 2 colleagues, Joe and Jane.
- They want one project with 2 goals (1 for themselves, 1 for Joe).
- They want a sub-project with 2 sections and 3 goals (1 for themselves, 1 for Joe, 1 for Jane).
This flow would allow us to cover the signup, onboarding, goals creation and invites. It does not take into account the second user experience on purpose as we're focused on the first user.
Establishing the baseline
We measured our Friction Index (FI) 2 weeks ago, and the results are below. Note that we counted the max number of clicks instead of going for the optimal path. By that, I mean that even when you could press enter to submit a form, we would use a click to submit it instead.
| # | Step | Clicks | Context-switch | Context-switch weighted (x3) |
|---|---|---|---|---|
| 1 | Signup | 4 | 3 | 9 |
| 2 | Email confirmation | 6 | 5 | 15 |
| 3 | Create your profile | 5 | 1 | 3 |
| 4 | Create your workspace | 3 | 1 | 3 |
| 5 | Create your first project | 1 | 2 | 6 |
| 6 | Create goal for yourself | 8 | 2 | 6 |
| 7 | Create goal for Joe | 8 | 0 | 0 |
| 8 | Create sub-project | 2 | 2 | 6 |
| 9 | Create goal for yourself | 8 | 2 | 6 |
| 10 | Create goal for Joe | 8 | 0 | 0 |
| 11 | Create new section | 4 | 0 | 0 |
| 12 | Create goal for Jane | 8 | 0 | 0 |
| Total | 65 | 18 | 54 |
Honestly, when I saw these numbers for the first time I couldn't believe that it was taking 65 clicks and 18 screens to go through this simple flow. 🤯. Here's another way to see that data: each step circle is proportional to the number of clicks or screens involved.
That really made me feel bad, but we had something to work with. Our FI was 119 and we needed to reduce that number.
Things we did to improve the user experience
Reduce context-switching
It's generally useful to take the user through a step-by-step process the first time they use your products. But it can quickly become painful if you keep that heavy flow for repetitive actions.
One example for us was the creation of new projects where we were taking you to a project form, and then back to the newly created project. We changed our approach to automatically generate the project as soon as you'd hit the create button. You could then edit the project title and other settings directly from the page itself.
Better inline-editing
A great thing about spreadsheets is that you can just click on a cell to update its value. This is far much easier than having to show up an entire form with multiple entries when the user only wants to change one parameter.
We implemented inline editing in our project view so that you could change most of the goals, sections and project parameters without having to go to another screen or trigger a popup.
Pick defaults values
Instead of always asking the user to fill in all the fields when creating goals, we would keep the previous values entered for the owner, score and deadline. That helps reduce the number of clicks required when creating multiple goals in a sequence as there a high chance that some of these values stay the same.
Focus on the right fields
A lot of the clicks were wasted on clicking on the first field of a form. We switched to auto-focus wherever it made sense. Once again it may look like nothing, but at scale it can become a UX burden.
The result
After 2 weeks of work, this is how the metrics improved.
| # | Step | Clicks | Context-switch | Context-switch weighted (x3) |
|---|---|---|---|---|
| 1 | Signup | 4 | 1 | 3 |
| 2 | Email confirmation | 5 | 5 | 15 |
| 3 | Create your profile | 5 | 1 | 3 |
| 4 | Create your workspace | 3 | 1 | 3 |
| 5 | Create your first project | 1 | 2 | 6 |
| 6 | Create goal for yourself | 4 | 0 | 0 |
| 7 | Create goal for Joe | 6 | 0 | 0 |
| 8 | Create sub-project | 3 | 1 | 3 |
| 9 | Create goal for yourself | 4 | 0 | 0 |
| 10 | Create goal for Joe | 4 | 0 | 0 |
| 11 | Create new section | 6 | 0 | 0 |
| 12 | Create goal for Jane | 6 | 0 | 0 |
| Total | 51 | 11 | 33 |
Our new Friction Index is 84, which is a ~30% improvement on the previous experience. It still too much if you ask me, and a lot of that has to do with the email confirmation step. But I'm super happy to see that we cut in half the cost of creating goals and projects since it's something that people will often do with the product.
Visually we can see that fewer steps involve switching context and we reduced the number of clicks in many places.
Data doesn't tell all the story
It's important to not blindly look at the numbers and set lofty goals without understanding context. If you look at the absolute numbers, it removes all the complexity of the user experience, and it doesn't help understand the investment required to keep things simple.
It's important to dig into the details and look at what's happening in each step. In our case, we have highlighted the email confirmation step. That's because it means we lose control of the experience at that point and things can be much worse than what we think.
Another thing is that a lot of the ideas to reduce friction came from talking to our users and observing them working with the product. Sometimes you can't cut corners, and it's better to have a couple more clicks, screens or steps to explain the value of your product. Other times you'll notice that you created new pains without realizing it.
Enabling users to do more with less effort
As I said in the intro, simplicity is a crucial feature for us. It's how we distinguish ourselves from the market, and it's essential for us to make sure we're helping our customers to get more things done faster.
If anything, I hope that this post will encourage you to take a look at your product and try to measure your own friction index.
Squadlytics is a continuous feedback platform that helps teams keep projects on track. We remove friction from sharing goals and make updates easy to do.
Top comments (7)
I love the "friction index" calculation. Definitely, something I'll use.
Thank you.
Nice article on an aspect of (software) engineering that is often forgotten; that of the experience. I look forward to more of this from you Sten!
Thanks! I'm hoping that next time I can do a more technical article: "How we built a Chrome extension to measure friction". 😬
something really important, but really often forgotten, thank you Sten. Great Effort.
I hope some JIRA UI dev ha read this article. Very interesting approach, I love simplicity and this could be a good framework as a starting point. Thanks!
Fascinating post and concepts! Really valuable.
One thing that wasn't mentioned was exactly how you define a "context-switch".
Maybe you could clarify that?
Of course! So first off it's a bit arbitrary but the idea was to have a simple framework that can be re-used time & time again and measure improvements.
So we consider that the user switches context when most of the page changes. A simple example is being on the
loginpage and then being redirected to your dashboard. That's considered a context-switch. It might make sense but for the user they still went from one view to a completely different view. Unfortunately you kinda need to have that if you want secured workspaces.Another example that can explain how we removed some context-switching is project creation. The process used to be the following starting from your dashboard:
(1) Click
create projectbutton(2*) Be redirected to a project form
(3) Fill in the form
(4) Click create
(5*) Be redirected to the project
I put a star next to what was considered a context-switch. We changed that workflow to be:
(1) Click
create projectbutton(2*) Be redirected to the new project with
Untitled project(3) Edit the name of the project inline
By removing the form there are less "screens" to go through and the user has less interfaces to learn. So the more we can let the user do actions in context the better.
Let me know if that makes sense.