There is a grand ambition for Salable and it's about understanding what that is. Once you work that out, you put together an interface that makes sense of all the things you can do with Salable. What you're doing is putting together something that’s hopefully as simple as possible.
You start with the end in mind?
If you reverse-engineer how you'd achieve something e.g. the plans and the way features are populated - that kind of stuff - you start to see how you build that, or how you'd want people to understand why it's built.
Do you attempt to put yourself in the shoes of the user?
I’m not a dev…I've got to get to the point where I understand it and once I've 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. Then once you've picked the right Lego pieces, you're home. And then the other question becomes: what other pieces do you need? So new things can be folded into it. But also maybe you've also got a little bit wrong…
Yeah! And we're not just talking about physical and UI. When there’s a headache, in some cases you might need to read the documentation twice. So 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.
Are you constantly thinking ‘for now it can work like this, but then for the future…how should it work?’
You have to reconcile that some things will be built for day one or even day one hundred. So you can't always put in what you hope is the cleanest or simplest solution because it just won't happen anytime soon. You should never think of it that way, because you've probably got half a bit wrong - the users will tell you how they want to use their products.
Is it easy to unpick what's been created based on user feedback?
Once you understand it and get your head around what you need to change, it's kind of delightful. There's nothing like research to guide!
You've described it as ‘delightful’, others may not feel favourably about feedback.
It's made easier because we're a small team. It means that there's less combative ego stuff going on…which will always occur, especially as teams get bigger.
If you build it and say ‘well, there you go - that's it!’ What would be the point?
…arms folded, no changes! There's no fun in that! It's what makes a product design a different sort of thing to ‘traditional’ design. The design is finished when you're done. But there is no ‘done’ especially if it doesn't start until the designer has their first ‘run’ of it. The only sort of guarantee is that in twelve months time, it would look nothing like what it started with, and that'll be true again another twelve. There's no guarantees of anything…you sort of trust the process, which isn't like anything else.
The design ego that you can have - that wants to do the most beautiful thing you can do - is pulled away from you. There's all these different collaborators and it's important that the designer is nothing more than a translator of the needs of the whole team, not revered as a sort of source of inspiration. Your gift and your frame of expectation is that you can translate needs into a plan for development. Ideally, people work really well with it, they understand it. And then once they're done with it, they can put it aside until they need it again.
If you're trying to allow for lots of different users or collaborators, that can be tricky?
Sometimes when looking at UX design, the simplest thing you could do is something in two clicks and part of me knows that's true. But I'm thinking ‘I'm sure I could do a five click one that felt as simple as a two…I’m sure I can make it work!’
You're trying to challenge yourself? Or are you playing devil's advocate?
I'm fighting the common wisdom. Because once in a blue moon, you will actually come up with something that is more functional from the common wisdom. The standards that can be applied to all use-cases…but occasionally you’ll be correct, but not always! It works perfectly well, but you’re also thinking ‘I'm sure there’s a better way to do that.’
