Updated: April 15, 2019
Prototyping in code at Craig Walker
Recently, I worked with Craig Walker on a project to rapidly prototype and test a digital service. I was involved in Phase 2 of the project. Phase 1 of the project was research into the validity of the service through conversations with potential users and eventual testing of a paper, then invision prototype. The stipulations for phase 2 were to widen the user testing pool testing with 1, then 5, then 10 users at 2 week intervals and to prototype in code… 😬
We were given the choice of what we might want to build the prototype in and we choose React. It is fast and flexible and easy to link up with APIs which was needed. It was also familiar to the team. Below are my take outs from the 6 week project.
The full time project team was design researcher Simone Mandl as project lead and myself as interaction designer. We had the support of Paul Noble, Ryan Phung, Dominic Kirkwood, Peta Farago in varying degrees across the project as well as the leadership of studio director Kernow Craig.
Why did we do it in code?
- To collect and then feedback actual data. This would create a more realistic testing environment.
- To allow users to test the actual product in the browser/device of their choice. Again, adding to the realism of the testing environment.
- As a challenge. The studio had done this before, however, for me, it was completely new and something I had wanted to do for some time.
- The paper prototyping in phase 1 of the project had given us a strong framework. This opened up the opportunity for phase 2 to be prototyped in this way.
How was the experience?
- It was intensive. Processes designed to avoid tech car crashes were vital. A git workflow, a design methodology, naming conventions and file organisation system understood by all team members were all important.
- I will never prototype in anything other than code again. The depth with which we were forced to explore the design was unparalleled. We delivered a far more complete picture of the product than we could have in designs and a flat image prototype. The interactions have been stressed tested in more depth, the designs are more realistic and the compromises you are inevitably forced to make have been made at a much earlier stage.
- You must be prepared to refactor previously built elements at every stage. This is basically the main job. I would estimate that, after the first week, 40% of the time was spent building new features, whilst 60% of time was spent refactoring existing ones and the design system to accommodate them.
- A lot of the design was initially created in code, However, when we decided features needed work, someone would work on that feature in a design program. We then updated the build from that design. This process avoided tedious maintenance of design files. We did not design or maintain areas of the design that were straightforward or relied entirely on elements already within the design system.
- The testing was great. Seeing people use the real product was nerve racking but was a much better way to test the design. Because people felt like it was more real than an flat image prototype they expected more from it. They clicked everywhere, they used browser navigation, they resized the screen, they read the modals and tooltips, they used the input and expected responses on their inputs… and then they fed back on how it worked with a more critical mindset.
- Some changes were much quicker than if we had to do them in design. Due to the component structure of React a lot of changes in the later half of project were big in design, but small in code. Simply moving a component from one place to another was easy, large layout changes that might have taken a few hours in a flat image prototype were simply a matter of changing one or 2 lines of code.
Are there any issues to be aware of?
- A concern rasied among the team was that sometimes we choose not to design a feature in a certain way because of the time it would take to build it. Opting for designs that were quicker to build. Whereas, within a flat image based prototype we could have designed it however took our fancy and worried about the build later. Personally, I have no problem with this. Speed of implementation is a real consideration with all projects from start to finish. Pragmatic decisions need to be made and making them early leaves us better prepared. Having to build it forces us to understand the issues early and come up with a design that works and is achievable. Ultimately, if we can’t build the first iteration of it quickly and easily it won’t get built in the long run anyway.
- This process can’t work in a siloed team. It is fully colab obviously. 🤝
What are some things to remember for next time?
- A url for user testing and a url for development. We had to pause launches of new code due to booked in user tests. This reduced the speed with which we could work.
- A workflow for hosting, api setup etc. to be prepped pre-project so we aren’t doing that in week 1.
- More realistic expectations around when user testing will fall so we can prepare better. Wrangling 10 users in a two week timeframe was a bit of a rollercoaster. We needed to test certain things with certain users so we were launching and unlaunching features rapidly. This was a bit of a headache.
- Extend my prototype framework to include all the useful components built in this project so we don’t have to build them again. These were small things like checkboxes that work with Formik, modals, tooltips, input variations and large things like a log in and account management flow which are pretty similar from project to project.