Summer quarter has come and gone, and with it, I am now a Master of Human-Computer Interaction and Design.
As I did at the end of last quarter, I’d like to take a moment to look back on what we’ve accomplished this quarter.
And, a refresher on who “we” is in that sentence:
- Justin Lischak Earley, project manager
- Jana Abumeri, research lead
- Nick Straughn, researcher
- Emily Fan, design lead
And myself, in a design role.
Having done all that research during the spring, summer was about prototyping and iteration.
Low-Fidelity Prototype
The term “low-fidelity prototype” might sound a bit negative, but they’re a wonderful, wonderful thing. Low-fidelity prototypes are easy to make, which makes them easy to toss aside. In the same way that you use sketches and wireframes to go through a lot of ideas very quickly, a low-fidelity prototype lets you try things out without pouring a ton of resources into making something pixel-perfect.
We went through several iterations, developing clickable flows that highlighted the key points of the features we were designing. Those flows in hand, we went back to the users, and gathered more test data – did they understand what the new features were for? Did the terminology and usage make sense? Was it useful?
High-Fidelity Prototype
That user feedback in hand, we went back and created a high-fidelity prototype. One of the main goals we had in mind with this was to have it, if not ‘pixel-perfect,’ viable for handoff to the developers who would be creating it. Instead of mapping out every possible screen, we identified the key user flows, and created a guided tour of sorts, a limited clickstream that showed as many of the possible UI states, without requiring us to create hundreds or thousands of screens.
As part of this, I started to wonder what stateful prototyping tools would look like. Think about it – using current prototyping tools, if we want to have a collapsable sidebar, we need to make two of every screen, one with the sidebar open, one with it collapsed. Once you start getting more states – say, to use a non-random example, if you’ve got multiple collapsible elements in a sidebar, and some user-configurable data in the main area – the combinatorics make it entirely unfeasible to create a realistic prototype. This… is a thread I’d like to follow up on in the future.
Delivery
And with that, our portion of the project was over. We’d been working up to it for quite a while, yet it still felt very sudden. The last bit to do was handoff, which happened as a Zoom meeting with a couple of the design leaders at Project Jupyter, and a pull request to jupyterlab/design.
Not to be cliche, but this project has been an amazing experience. I’ve learned a lot in doing it, and I absolutely loved working with this team.