When faced with an aggressive timeline to launch a new product, it can be easy to fall back into a waterfall project process: complete all design work up front and hope that it speeds up your development output. I have rarely found this to work as intended. When my team was placed on a project with only 3 months to launch a new mobile product, we decided to try something different. Instead of front loading design or having the design team work ahead, we had developers become part of the design process and create the product together using a blend of traditional design artifacts and prototypes built in Xcode. We called this process “Practical Prototyping”.
Much of our early design work was done on the whiteboard as a team: 2 iOS developers, a visual designer, a content strategist, a project manager, and myself as the lead interaction designer. The team worked together to map out the app, stub out features, and design interactions. The iOS developers stubbed out rough UI in Xcode to test what we were sketching on the whiteboard. This allowed us to move quickly, iterate, and make decisions based on actual platform constraints.
Because much of our design work was done in Xcode, it was easy to work within the constraints of iOS. We wanted to ensure we created a product that was maintainable, usable, and reliable for our client over the long term. Clever visual design helped make standard iOS components look customized and polished.
We still created design artifacts in Sketch to serve as a record of our decisions we made together as a team. We used object maps to ensure we were capturing necessary functionality in the UI. The wireframes and annotations we created in Sketch followed the work we were already doing in code and were primarily used as internal documentation to ramp up additional team members.
Following this process, we were able to give the client a real version of their app running on an iPad at the end of the first sprint. This initial build allowed the client to see and feel what would become their final product. At the end of each sprint, the client was able to clearly see the app grow and become more refined as we added more features and visual design components. By using the actual coded app in demos, instead of static proptypes or wireframes, we were able to stay aligned with the client and avoid surprises.
If we had stuck to waterfall or not used practical prototyping in our design process, we likely would have run into snags where elements of the experience would not have worked as expected once it was coded. By bringing our interaction ideas into code early in the process, we were able to design to the nuances of the technology to offer up the best experience to our client’s customers. Practical prototyping is a great tool for cross discipline collaboration and quick iterations and helped us ship a quality product that the client was excited to share with their customers.