How might we build and test a business hunch?
Bluescape, a division of Haworth, built a touch-screen whiteboard for enterprise companies. Now they wanted to know if people would use a version of it at home on their browser. Provided only with the idea, my team and I intended to find out.
How would we know we were on the right track?
Before jumping in, I took a step back to think about an underlying question. Every product taps into a psychological, physical, or emotional need.
Which need would this product fill or enrich? For Bluescape Now: People have a need to gather, share, and work on ideas together.
This provided a simple starting point for how I would approach the next set of questions. Where should my team and I look for inspiration? Which research objectives should we focus on? How might we design the experience? Where would the product succeed or fail, and why? How were other solutions successfully answering this need?
I framed the team’s answers with a modified Gothelf and Seiden’s hypothesis-statement from Lean UX: Applying Lean Principles to Improve User Experience. The hypothesis-statement is usually broken into four parts.
“We believe this [business outcome] will be achieved if [these users] successfully [attain this user outcome] with this [feature].”
For Bluescape Now, I framed one statement as a product-driven hypothesis and with it, a project plan.
If we start with the solution first (retrofitting Bluescape Enterprise): We believe there is a need for personal project collaboration so that collaborators can plan a home renovation project or organize a wedding or do their homework together. We think we can be successful by making it easy to start using; appropriate for smartphones and touch devices; and having a compelling but natural feature/interaction. We will know we are right/wrong when we see adoption.
Workstream A: Converge
Build towards a single direction to be beta tested at the end of the engagement. We would converge on a single purpose towards high fidelity and functionality.
For the other, as a research-driven hypothesis with its own workstream.
If we start with the problem first, “A need to collaborate on personal projects” We believe there is a need for personal project collaboration so that collaborators can plan a home renovation project or organize a wedding or do their homework together. We think we can be successful by combining research and prototypes to help validate market/product fit.
Workstream B: Diverge
Conduct a series of short experiments to help validate market need and want; technical possibilities; and explore ideas for new micro-interactions. We would diverge on multiple ideas and aim to cover more territory.
Workstream A: Research by Building
The developers had a tough challenge ahead - to work with raw Web GL. They would re-construct basic operations like selecting the correct object on the z-index. It was like going back in time and churning your own butter. Development would be on a slow, steady march.
Every feature required tremendous effort, so I grouped the work into test-ready milestones. This was a mechanism for the team to stop and assess the work on a regular cadence. These checkpoints were a way to ask ourselves if we were on the right track and if we needed to change priorities.
The internal usability tests would lead up to a larger, private release. At which point, a participant would be able to complete a meaningful task from start to end (guerrilla testing outside the immediate team require a level of preparation and documentation, so I was mindful of when we would initiate those tests).
The team and I conducted competitive audits and research activities. One was an experience journey I mapped by feature:
Workstream B: Research by Asking
There were three questions I focused our research efforts on:
- How might we understand how people currently plan and work on personal projects?
- How might we understand how someone would use this consumer version?
- How might we understand if people wanted to use this product?
Paul Norris took the lead on investigating these. For the first, he sent a nation-wide survey through Survey Monkey. For the second, he conducted an internal usability test. Last, he designed a faux marketing site for the product.
Altogether, both work streams informed the private beta MVP definition:
Create multiple sources of data points
The two work streams, Converge and Diverge, was a way to scout as much ground as possible. It allowed the team to search near and far by using both startup and design strategies.
Tomer Sharon writes about the myopic tendencies of the Lean Startup approach. It was a timely reading for this project.
The question “How do people currently solve a problem?” is important because it’s the biggest blind spot of the Lean Startup approach and its Build-Measure-Learn feedback loop concept. Getting feedback on a product and iterating is generally a convergent process based on what you know, what you experience in the world, what your friends tell you, what you whiteboard with your team, and what analytics tell you about your product. But sometimes the solution is outside. - Tomer Sharon, Validating Product Ideas Through Lean User Research, 2016
Experience tenets are a useful way to gain perspective. Especially when the team working day in and day out on the details.
If the feature or micro-interaction contradicts a tenet, it’s a signal to discuss why. They are not hard and fast rules, instead they act as a baseline for a coherent experience.
For Bluescape Now, I wrote the tenets as though someone was talking through a product they were using. Like, “I just want to put a picture of a corgi. Shouldn’t it be as easy as Googling for it?” Under each statement would be how it translated to design.
Getting perspective. It’s a reflex I haven’t seen designers write a lot on, yet it’s been an invaluable skill to practice. In one moment, I’m working on the minutia, like a micro-interaction. The next I need to jump to the 10,000ft view, like marketing trends. This transition reminds me of a group traveling on foot. Every so often someone would scramble up for a view, to scout the path and see a little further. Repeating this action, climbing up and descending down, can be as mentally exhausting.
Bluescape Enterprise had a deeper and darker color palette. For our MVP, I lifted the hue on the colors for a brighter tonality. Both products would appear related yet also their own.
The product needed to work on a range of ergonomics. Such as laptops with trackpads, desktops with mice, tablets, and touch-enabled televisions. So the UI needed to be readable at a glance and at any scale.
I pulled cues from widely-used patterns, such as a wide search bar and a dock. I made the tools distinct in both shape and color to distinguish each one.
Shadows, highlights, and gradients implied tactility and touch-ability. These effects hinted at the 3D technology the interface was sitting in.
We transitioned a prototype over to Bluescape for completion. They partnered with Intel to release Bluescape Now on Intel’s Unite television, a workplace tool for collaboration.
About the project
Lead designer at Substantial
UX, UI with Paul Norris
Built with Web GL
Flo came on as the Lead designer for a new consumer product we were exploring at Bluescape to complement our enterprise offering. It was new territory, and more significantly, new territory within a product space that was/is still in its early definition phases. Flo dove in, both to understand the competitive aspects of the space, and to see where there might be fruitful and compelling associations to be drawn outside of the space. She infused all her work with rigor and focused imagination, as well as a sense of pride of ownership you don’t always see in consultancies. She’s also a great conversationalist–would work with her again in a second. - Andy Markham, VP of Design at Bluescape