We had an interesting discussion going on in #core-dapps on Slack. It sort of went like this:
Dev: Can we release our new coffee flavor?
PM: Generally it needs to be user validated in some way.
QA: Do we need UX input?
Dev: I’ve heard from users they want this new flavor. And being a user myself I also believe this new flavour is better. Also, you don’t have to drink it.
PM: Time is an investment as well. We should spend time on issues we validated.
Community Manager: I’ve heard it too!
PM: Cool, more feedback. Let’s release this flavour.
So what if we want to release another coffee flavor, or maybe a machine. How do we decide? How much feedback is enough? Should we merge only after UX has been involved? Should we start working on features only after we receive input from UX/UXR?
The following are criteria that flowed from our discussion to guide what a given swarm should work on when their work impacts the User Experience directly.
New feature adoption criteria
- Work on problems that impact our goals.
- Work on things that will help us learn about usage and users.
This then leaves the question of whether and when input from UX/UXR is required. The answer that followed our discussion is actually: Never. But wait, you do need something else: a Design Process.
We build our product together, meaning, we create the user experience together. And while we’re at it. We create the experience together with the birds, the trees and anyone else out there working on similar products that shape people’s expectations. No user experience is created in isolation and it therefore feels kind of funny that we would trust one ‘UX team’ to control it. Simply not possible.
That said, at times there is a stronger need for a solid Design Process. Typically, people in the design team have built a routine and intuition for this process. Therefore it makes sense, but is not necesary, to involve them.
Here’s when in my view it makes sense to follow a more extensive Design Process (Learn, Design, Build, Measure, Repeat)
Guidance for when to use an extensive Design Process
When First time right is important. This depends on:
- Type of feature (Essential, Frequently used, High risk)
- Demand (Multiple users accross multiple platforms request it)
- Potential reach (number of potential users affected >80%)
- Dev risk (Risk of having to rebuild when the feature isn’t well-received or leads to usability issues)
- Purpose of the feature. (When we are actively trying to learn something through experimentation with several designs and implementations)
What do you think? Are there other situations in which we need a design process? Do you agree with the premise that we’re all responsible for the UX of our products?