I'm Connor, a toolmaker and experience designer. I am a systems focused UX/UI professional who specializes in advanced interaction prototyping, information architecture, and data-heavy design.
The following are some of the concepts I've picked up over the years that help explain my design thinking process:
Life is filled with problems that we all contend with every day. If we’re hungry, we find something to eat. If we don’t know what to eat, we may ask our significant others to choose for us, to which we may say “No, not that”, or “I don’t know, you pick!”. These regular everyday tasks that we as humans must complete, are either solved by us, or solved by the ones we relegate these problems to; because sometimes it’s nice to have someone (or something) else make decisions for us. Product design, and digital design in particular, is built around this very same dilemma of human choice. Whether you know what you want, are undecided, or want your choices to be made for you, there is some kind of app or digital product that will provide you one or more avenues with which you can complete your task. A food app can, by default, give you a list of choices to choose from right on the home screen. A newsfeed can give you a list of articles based on an algorithm honed by your past choices, removing the need to think about what you would like to see before seeing it. And if you're feeling particular and know what you want, these same apps will usually give you the choice to manually search or navigate to that thing. While the choices may be seemingly endless in a digital experience, it's up to product makers to make these tasks as pleasant and efficient as possible within the given budget and timeframe.
All these possible choices and tasks can be cumbersome, to say the least. Being overloaded with decisions has become a regular part of modern life, and is a puzzle in of itself. And so, over the years, the general goal of many digital products (aside from those like social media/games) has changed from 'session length'—that is, keeping the user on your app/site for as long as possible—to 'task completion', so that users can get in, do what they need to do, and then get out and go about their day. Ease-of-use and proper, helpful functionality that emphasizes speedy resolution is what keeps them coming back, and thus has largely become the focus of prevailing sites, apps, and software. However, designing for task completion is easier said than done. The variables that make up good task completion design will of course vary depending on the given task, or set of tasks, and includes (but is not limited to) the following:
- Show the user what they need at the right time, and nothing that they don't
- Anticipate their desires/actions, and display choices accordingly
- Make it so someone needs to use their brain as little as possible to complete the task (do the math for them, use plain language, keep track of information/codes for them across multiple screens, etc.)
Other traits of good task design also happen to be general principles of digital (and physical) interface design. These are important components of interacting with and navigating a UI; the ability to identify what something is, and what something isn't, in order to help one determine where to go, what button to press, or something of the like:
- Cohesive and consistent interaction patterns for situations that are the same or similar
- Cohesive and consistent design language/symbolism for situations that are the same or similar
- Conversely, a component/feature that is notably different or unique from others in the UI should be given its own stylistic/behavioral treatment (sure, you could make everything a table, but should you? It's easy to get "lost in the woods" when everything looks like a tree)
- An organized structure that conveys a clear hierarchy of information
- Subtle animations of elements/components that help reinforce the action or event that is taking place
- Communications/messages/helpful tips (how can this UI or language be misinterpreted?)
Overall, task completion is the name of the game when it comes to interface design. And although it may at first glance seem obvious that the whole point of an interface is to, of course, help one complete tasks and solve problems, what often becomes murky is the methodology for piecing together a 'system' for creating that interface. Additionally, the challenges of development, scope, and time constraints can complicate such an effort. However, if we learn to think deeply about these "human-centered" puzzles with care and consideration, and invest as much focus into identifying as many variables as possible, a product with little-to-no vision can begin to take shape.
The ability to think deeply about something is part of what makes humans special. We all at certain points will take the time to ponder, giving us insights into things or ideas previously unknown to us. A UX designer is often tasked with thinking very deeply in this way, very often, about the most pragmatic and useful ways that humans want to interface with a product. And the more you think deeply about these kinds of problems, the better you get at it. It’s a skill, just like any other. But unlike a skill where the focus and outcome is very narrow and singular, learning how to think deeply is a key that can unlock many doors—by way of systems design thinking—how parts of a system coincide with one another to generate a particular outcome. Learning how systems either currently function, or ought to function in the future, is a key ingredient to becoming a good problem solver in this space.
To be able to construct, deconstruct, and reconstruct a system is a superpower in life in general, but it is especially crucial for designing, or redesigning, a functioning UI. Identifying all the variables involved in a system is the only way to understand how it currently works, could work, or should work. When reworking an established tool, you need to be able to "take the engine apart before you can put it back together again", because every piece (usually) serves a purpose, and changing one thing can cause the whole system to fail—from both a usability and an engineering perspective. Therefore, having both a "mechanical mind", as well as a strong sense of user empathy, is integral to crafting smart and memorable experiences. Failing to learn systems thoroughly enough to identify all the variables can cause additional meetings and design work that postpones deployments or threatens deadlines. Taking the time to do a proper analysis and deconstruction at the beginning of a project can save time further down the road.
Okay, so how do we know we’re thinking the right thoughts? Thinking 'deeply’ and thinking 'clearly’ go hand-in-hand, but just because you’re thinking deeply does not mean you're also thinking clearly. Just as having a good “economy of words” is important in terms of communication, so too is having good ‘economy of thought’. As product people, we often get lost in our own self-imposed maze of variables to consider and then constantly reconsider. Product owners or managers may have a basic problem statement formed for what they want to accomplish, but in the pursuit of solving one big problem, it is often the case that many more smaller problems must first or simultaneously be solved, and usually solved upstream, with retroactive changes to other parts of the system in order to jibe with the new ones. Learning how systems function (Ideally during the wireframing phase of a design project) often requires asking the right questions to the right people in order to build a competent and thorough collection of variables, with which we can then use to help give dimension to the problems we wish to solve. This may include prompting user tests, or reaching out to other resources within the company from whom you can glean some kind of answer, and make clear the system's intended function, or the (perceived?)goals of a particular type of user. This may introduce or expose assumptions that can be challenged, in order to separate fact from intuition.
Our intuitions can and do help point us in the right direction, but by their very nature are quite tricky, and are hardly a substitute for distinct argument or explanation. While design intuition is a powerful tool that can be honed over many years, it can also lead us astray if not used properly, which is true for all members of the design process, not just designers. Our anxieties and biases can influence our intuitions, consequently manufacturing a disconnect with our users and their needs. If we’re honest with ourselves and the limits of our intuitions, and remember to check in internally now and then to see if we’re 'thinking clearly', we may find that we are indeed, or indeed not. On a similar note, the redundancy of group discussion and feedback can help alleviate our intellectual blind spots and keep our intuitions in check. However, just like how intuitions can lead us to faulty assumptions, so too can the dynamics of (what is known in the psychology branch of Human Factors) as 'groupthink'. When groups of colleagues get together to discuss problems and how to solve them, some of the more vocal or authoritative members of the group may dominate the conversation, allowing for false assumptions to take root in a system, bypassing the benefits of group redundancy, and therefore resulting in points of failure—which, in the case of UI design, means users not being able to complete their task(s) effectively.
Asking “why?” again and again, and outsourcing the problem when we’re stuck, can help us to think more clearly and make choices that will distinguish the good thoughts from the unhelpful ones, and thereby, speed things up. How will this design choice affect the product goals? What about dev time? Will this give the majority of users what they want? What design tradeoffs can or should be made? Am I showing the user what they need at the right time? Is progressive disclosure appropriate for this situation? Or perhaps they need more functionality at their fingertips... Do the different parts of the website need to match in appearance and function? Or are these things different enough to justify making them look and behave differently? Perhaps I shouldn't just make this into yet another table... Thinking clearly requires us to ask the right questions at the right time, explore our intuitions, identify variables, determine use cases, and think of how things could go wrong so that they can be corrected way before launch—or even before being developed, for that matter. As designers, it's our job to clear the UI fog and reveal a path forward.
*None of this was written or edited with AI 😊*
Please include as many job details as you can and I will respond promptly. Thanks!