Building UI for change.
updated over 1 year ago; latest suggestion over 1 year ago
This proposal has been withdrawn...
Do you feel good after finishing a new screen or transition? Do you feel accomplished when the screen is complete and it looks exactly as the designs?, Then you run the app and play with it again and again? I do at least. Then you show that to your friends and family and they don’t really understand why you are so happy about it. “It’s just a button.” if you’ve experienced this, this talk is for you.
That feeling of accomplishment is great, but when you’re building UI, not everything goes that smooth.
You might be using agile methodologies, working side by side with product, design and backend, defining the core features of the app, getting really excited about this new idea until… you get your first rough draft of the UI. Maybe it’s just a photo of drawings on a whiteboard, or a black and white mockup. That might not be very exciting… I understand that implementing the core features are the most important part, but where are my beautiful designs? the ones I can show off proudly after implementing?
It doesn’t end there, you already know those are low-fidelity mockups, and you know after some testing and design time those will change to some mid-fidelity mockups, and then change again until you finally receive your shiny new “high fidelity” mockups or “final” designs. Let’s keep the quotes on those, because even if they are final or hi-fi, they will definitely change.
In this talk I’ll go through:
- My experience working in multiple applications starting them from scratch.
- Some ways to reduce frustration when creating new screens. Starting with lo-fi mockup, and how they can evolve to become hi-fi or “final”.
- How to organize the different inputs designers give you (Images, Colors, Fonts, Positions, etc.).
- Using and naming those design inputs in the app and make them easy to tweak.
- How design can obfuscate our code, making it harder to understand the intentions or main functionality and what to do about it.
- A proposal about how to organize your styles and make them reusable, keeping the functionality of your code clean.
As a UI developer this holds special interest for me. I'm really curious how you recommend developers deal with UI that's not necessarily coded in IB.