Design lessons from my experience in hi-tech
In an ideal world, designers receive clear product requirements based on user research. The requirements address goals, needs and pain points. Then, the designers undertake task analysis, breaking down each critical task required to get the job done. The user flows are mapped out immaculately, even those involving multiple personas. The work is validated with customers. Then come initial wireframes. And more validation with customers. On to prototypes, validation, detailed design, testing, design review, etc.
BUT, in the chaos of ‘real life’, things are different. A designer can receive a half-baked complex feature that suddenly becomes high priority and high urgency. And by the way, we have to present a prototype to the customer next week and then do handoff to R&D a few days after.
So, what to do?
Approach 1 — Like this, I won’t design
Some UX practitioners may refuse to go along with this, citing upholding professional values. The buck stops here. They will only work according to ‘proper’ methodologies and refuse to compromise. It becomes a matter of principle. Of ‘educating’ their colleagues. They trust the process, and if it is not adhered to, they simply will not cooperate. This is in the name of the profession. In the name of quality. In the name of long-term efficiency, since doing it wrong fast now is much more expensive than doing it right slower deferred. There are upsides to this approach. Being adamant can demand from colleagues to come prepared and work properly next time. It ensures that this will not repeat itself, since the stakeholder who made the request for UX assistance does not get what s/he wants. But there is another approach.
Approach 2 — Let’s see how I can help.
This approach says lets make lemonade from lemons. You can find yourself using prototypes to assist in defining feature requirements. This means there is no time for proper discovery. No time for validation. For research. For testing. It falls short of ‘just-in-time’ design — it’s closer to ‘hey I’m going to be a few minutes late for the handoff meeting’ (since I have to finish the design!). This is probably not what ‘lean’ folks have in mind. It’s too fast. It can be more costly to fix later. The list of why it is problematic to work like this is long. BUT, the upside to this is that it may be better than not having any ‘help’ from UX. Stakeholders- PMs, developers, whoever, — are going to run forward without the help of the ‘spoiled’ designer. So if you, as a designer, can improve what they’re doing even a little, even if it’s not ‘proper’, then you are adding value. In this context, helping is not viewed as a compromise of professional values, but merely of doing the best you can given the far-from-ideal situation you find yourself in.
Conclusion
I framed this dilemma in a way that probably gives away which I lean toward. But I grapple with such questions. It’s hard to ignore, also, that there are non-business and non-professional motivations for doing work, even if you are within the legitimate boundaries of a salaried position. For example, working with some Product Managers you may give them faster turnaround, or be more willing to cut corners for them. It’s solely based on your relationship with the other human. It’s not rational, and not really fair. But after all, all of us humans are human.
Thanks for reading.
About this Series
This is part of a series of UX Case Studies based on my experiences.
About the Author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and international B2B companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
