Over the last eight weeks of IDSE201 Rapid Ideation and Creative Problem Solving I’ve been learning about how to ideate the design of a user interface by wireframes – in this case for a theoretical Thermostat design.

As a reminder wireframes are models for user interfaces (UIs) that lay out the features of a design – kind of like how blueprints work for buildings. They wireframes may look polished, but they don’t represent the final look of a design. Wireframes are for planning and figuring out how all the elements in a system are laid out. This lets designers like us test and iterate – or come up with multiple, refined versions – before we come up with a final layout.

During this process, I came up with two completely different designs before finally settling on my third. By going through the design process and then testing them, I was able to test my assumptions about how real users would actually interact with my system.

The main test method I used was think aloud testing. Think aloud testing involves paper prototypes, printed physical versions of the UI design, showing them to a test subject and asking them to complete a task like raising the temperature. The user speaks aloud describing what they are doing and thinking in relation to the task. This is a quick and easy way to see if you’re design is functional and if the design assumptions you made were right – or wrong.

Going through user testing on my various designs, I learned a few things:

Users won’t be able to manage the same level of complexity in a system as a designer is able to. While this may sound obvious, after spending hours upon hours thinking and perfecting a design, it’s easy to make assumptions that a task or feature will be easy to use when it’s really not.

We’re not just really designing a thermostat. We’re learning how to think in systems, understanding how the parts and the whole relate to one another. We applied the same synthesis and sense-making skills we’ve learned in design research to simplify and iterate upon a user interface.

You need to design in flows, not screens. Early on in the process, I was focused on getting every little detail right. I neglected to think in Hero Flows – the sequence of steps a user might take to complete a typical task of the system.

Start with assumptions, then move to validation. Designers need to use their abductive reasoning skills and make assumptions when they first begin to prototype. Without doing so, there would be little creativity and originality in our work, and everything would probably end up looking the same. But while assumption is important in guiding our work, we still need to test it with users. Our designs still need to function within the mental model that guides users when completing a task.