Despite the fingerprints on your MacBook screen, interacting with your mobile app designs on a phone will be far better than on your computer. Your customers won’t be interacting with static designs, they will be holding their phone with one hand focused on completing their desired task.
Those static designs won’t tell you how the button interaction feels, or if the transition timing is correct. On device you won’t be jumping between random designs, instead you path will be dedicated by the task at hand.
As designers we have hopefully moved away from fake data and lorem ipsum for our text. Your design should include real data, and so should your prototype. The more varied and responsive your data, the better your prototype will be.
As the iPhone was being developed, having a working hardware prototype loaded with the beta software allowed the designers to not only identify blockers but overcome them before bringing the phone to market. In fact industrial designer Jony Ive had said in an interview that the iPhone project almost came to an end when they discovered the phone would be dialling number when brought to a person’s ear. This meant a design solution had to be devised in the software, using sensors from the hardware.
Your prototype uses a lot of that same hardware, from the multi-touch screen, to haptic feedback and the devices many sensors.
Since design iteration is one of the first phases in both your design and prototyping process, this phase may easily be served with the companion app for Figma or Sketch. After interacting with your static designs on device, you’ll likely have improvements to make to the design. Location of elements might be more obviously awkward, size of text and spacing may not be readable.
At this point in your process, your prototype is more like a living document, constantly being adjusted and improved to get a workable design. Throughout the entire process you’ll continue to iterate as you receive more feedback, and most importantly put your app through usability testing.
How does SwiftUI help?
In a word—accessibility. Unlike design apps and prototyping software, adjusting the type size is easily automatic in SwiftUI. By tying your type styles to the in-built set of styles, if the customer requires a larger text setting, either slightly larger or with the accessibility range turned on, your prototype will dynamically respond.
Working your way through the text sizing will help you validate if your design holds up, how the content will flow, and allow you to iterate the design to avoid issues. By considering these states early will massively improve the collaboration with development. Instead of explaining the various states through a minimum of 12 designs, your prototype will be able to show your developers exactly how you want the design to respond.