#ModevUX Design, Device, Delight

Design to Delight

• Personalised.
• Responsive to orientation, tap and gesture.
• Culturally relevant.

Shared context is not just about sharing, about grind between designers and developers, “keeps your friends close and your developers closer”.

Sharing context:

• Early and frequent collaboration.
• Design considering development.
• Implement considering user experience.
• Having trouble? Colocate!

Get to point where everyone has a common expectation.

Build a device specific experience.

Design for reality. Don’t let technology drive your design, what that really means is don’t let developers drive your design, but absolutely technology is going to influence your design. You will run into walls, these walls aren’t make believe, you won’t be able to get around them.

Device reality:

• Physical size and orientation.
• Pixel dimensions and density.
• Network and disk IO.
• Processor speed.
• Available memory (main and video).
• Device platform.

Native applications do better with animation, handle things better, because they get you closer to the hardware. HTML is a very abstract platform. It’s important to help devs and designers understand breaking point of device. Ask: how far can we push it?

As you download images to the device, it will download and try and load them. It will only be able to do a little bit at a time. So when the user scrolls, if they scroll too fast, webkit won’t be able to render. What wound up doing was finding faster ways to paint to the screen. Showed placeholders first, wait to do activities until the user stops moving – this is viewport based.

Design for Time

It’s not about making something that will be relevant in 10 years, as you’re building the interactions in applications, plan for time, because even micro interactions take time. In prototypes, when the user clicks things happen very fast, this can build an expectation about that. That time wasn’t accounted for in the beginning. If that had been accounted for, it would feel more relevant and applicable.

• Rather than build to best case and recover, build to a realistic case and improve.
• Avoid chasing unicorns.
• Beware of immediate content updates.
• Plan for graceful introduction of resources over time.
• Preload carefully.

What are the rules regarding when to update the application? This are design problems. Need both design and dev discuss upfront, if left it to devs it will be left to the end and will just pop in. Find ways to address these issues early on.

Keep in mind: collaboration, innovate within constraints, plan for time.