Designing Salable; keeping the user front-of-mind and the relationship between functionality and journey. (aka what Lego pieces do I need?)
Interview with Dan Sturman, Salable UX/UI Designer
When you started this project…what were your initial thoughts about Salable; the way it should look and behave?
There was a grand ambition for Salable (there still is of course) and it was about understanding exactly what that was. And once you work out what that is, you then get to put together an interface that makes sense of all the things you can do with Salable. Not trouble the user with things that it can’t do yet…that becomes like a political question. Because what you’re doing is putting together something that’s hopefully as simple as possible. In the case of what we came up with for the MVP, it’s something that allows you to plug in your app. Then you create your plans…what you’re doing is creating a really smart pricing table. That’s what this version of Salable is doing. And actually, during that process we over-engineered a few things and kind of under-engineered some things.
What do you mean by over-engineered/under-engineered?
There’s some functionality that will eventually one day evolve, (for example) how you churn a plan. So when you’ve got a plan of one thousand users on it and you want to suspend it and choose a new version, you can’t just suspend people or move them. But to do a kind of clever system where, after six months they’ll churn…the thinking around that was quite complicated. But we wouldn’t need that until later anyway…so we sort of dropped that for a bit, because it wasn’t going to be needed for a while.
When you first looked at the requirements, you had to separate the longer term functionality from what was needed ‘right now’. Therefore it needs to do that immediate stuff really well, because it forms part of the foundation. Does that mean you start with the end in mind?
The very first version we spent a year or maybe longer working on it. Designing it, building it and improving it. It’s something that a vendor sets up one time and then they press go…it runs itself. The heavier stuff is when you’re using it more as your work platform…there’s more moving parts. But we’ve put together the really simple back-end stuff; you set it up and you let it go.
So we wanted a smart way to make a pricing table that was self-filling. So if you reverse-engineer how you’d achieve that…the plans and the way features are populated; the plan and product level — that kind of stuff — you start to see how you build that, or how you’d want people to understand why it’s built. Because what you’re doing is giving an illusion that you’re moving things along, when all you’re doing is putting code in a table. I think it’s like Lego…to make sense for users in their heads…as it develops we’ll still be cognisant of how it sits in their brain.
What you just described there, the longer term thinking versus the immediate stuff — what goes on in the background versus the foreground…is that ‘business-as-usual’? Or did you have to employ a different skill set, or think about things in a different way?
I’m not a dev…I’ve got to get to the point where I understand it and I think once I’ve probably got to that position, that’s probably where other people (users) might understand it as well. So you become a communicator or a translator. And the devs are really patient when they explain things to you for the 3rd time! So the first sprint is just ‘divining’ how it should be understood in your head. And that’s rare, because you only really do that once, in a project like this…after that it’s a UX design.
Then once you’ve picked the right Lego pieces, you’re home. And then the other question becomes: what other pieces do you need? You’ve got that visual language…that kind of mental image of how it’s going to work. So new things can be kind of folded into it. But also maybe you’ve also got a little bit wrong…
Did you have to ‘un-build’ any of the lego pieces?
Yeah! And we’re not just talking about physical and UI. We discovered very recently how certain payment integrations work. Some of them are more friendly than others, as to how you take information with your payment provider. They just drop that code into Salable and it’s working. But another one we’re working with, there’s two back-and-forths. You have to leave one browser to go to another, twice — open a tab twice to do the same thing. Which is so alien to how you do it with most of them. It made me think that maybe payment integration should be introduced completely on its own…set apart rather than as part of the flow of creating a product. Because it’s just their own thing…every one is different. So by virtue of that bit, they’re sort of almost self-contained.
Everything else in the experience is quite slick…then this happens and you have this rather kind of awkward point. Let’s just keep that away from users, not alienate people from the slick experience of Salable. When there’s this one bit of a headache, that in some cases you might very well need to read the documentation twice. So maybe you need to think about a new lego piece for that (or maybe use that brick with the little door on the hinge!). It’s just an experience that you don’t want people to feel that’s reflected in the rest of Salable.
So that’s quite a lot to think about isn’t it? Because what if that payment provider then changes that gateway…?
Obviously we’ll have different sorts of users. We might have technical users that would be brought in to line things up. Or there might be marketing people who are just going to be there every day, using it as their platform. Their job isn’t to know about how payment integrations work. So how would we naturally want that to one day be a ‘permission limited’ thing? How is it then part of that kind of clean flow, when it doesn’t need to be. You evolve your thinking that way, but hopefully the ‘soul’ of it remains.
Part 2 coming soon. Interview Louise Walden.
