Updated: April 22, 2019
Prototyping in code at Craig Walker
In 2019, I worked with design studio 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 had been research into the validity of the service through conversations with potential users and eventual testing of a paper, then flat image prototype (ie. InVision). The stipulations for phase 2 were to widen the user testing pool by testing with 1, then 5, then 10 users at 2 week intervals and to prototype the service 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. It was also familiar to the team.
Why did we do it in code?
- To collect, and then feedback, real data. This would create a more realistic testing environment.
- To allow users to test the actual product in the browser/device of their choice. This would add further realism to 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 a file organisation system understood by all team members were important.
- The depth with which we were forced to explore the design was unparalleled. I will never prototype in anything other than code again. 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 stress tested in more depth, the designs are more realistic and the compromises one is 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 essentially the main job. I would estimate that, after the first week, 40% of the time was spent building new features, whilst 60% of the time was spent refactoring existing ones along with 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 would then update 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 user 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 realistic than a 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 from their inputs. They then provided feedback with a more critical mindset.
- Some changes were much quicker than if we had been required to do them in design. Due to the component structure of React a lot of changes in the latter half of the 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 two lines of code.
Are there any issues to be aware of?
- We were sometimes concerned that we were opting to design a feature in a certain way because of the time it would take to build as opposed to what was the best design. Whereas, within a flat image prototype we could have designed a feature however took our fancy and worried about the build later. Personally, I have no problem with this sort of “enforced pragmatism”. Speed of implementation is a major 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 a feature 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 must be fully collaborative.
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, deployment, API & database set up could be prepared before the project. This means we wouldn’t need to do those things in week one.
- More realistic expectations around when user testing will fall so we can better prepare. Wrangling 10 users in the two week time frame of the final sprint was a bit of a roller coaster. We needed to test certain things with certain users so we were launching and then rolling back features rapidly. This was a bit of a headache.
- I would like to 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 as well as large things like a log in and account management flow which are pretty similar from project to project.