Building What You Design
I’m teaching myself iOS. Before that I was primarily focused on mobile design. I’ve found interesting the new transparency with which I can see through the “design stack.”
Before learning iOS, I would design with the user in mind — in pursuit of that perfect user experience. Now I design with both the user and the engineer (me) in mind.
If a design is marginally better for the user, but much more difficult to build, is it in fact the best design?
It’s a new question I’ve been wrestling with. We’re in the business of building things that look great, work great, and also ship quickly.
Having insight into each part of the process is forcing me to make engineering related design decisions at the UI level — sometimes consciously sometimes not.
It makes me realize how costly some “design-y” decisions can be to the actual building process.
My main perspective shift is that “design then build” may be a fundamentally flawed workflow. Engineers should be alongside designers when scoping projects.
The best design may be the one that minimizes the time-to-build/user-benefit tradeoffs.
This brings me to the next question I’m wrestling with: Is pure user-centric design bullshit?
The tradeoff between time and polish is not an engineering problem, but should be a framework for software design itself.