Designing in your own mind

It’s easy to ignore your user in the design process. Computer scientists or programmers entering the field of immersive and experiential media might find themselves focusing on creating good code or worrying about the complexity of the software (and how to avoid scaling issues). Artists might be focused on presentation and meaning in their art and might not spend any time working through the real nuts-and-bolts usecases of a user.

User-centric design has become more and more popular in general technology innovation. This has not really bled into interactive and immersive media though. We tend to keep to our own code, in our own heads, and with our own ideas. We focus on the here and now, and with looming deadlines, we rush to get something stable up and running. I don’t even think you need to pursue formal user-centric design practices. All you need to start is to spend a bit of time clearly thinking about:

1. Who is my user?
2. What are they trying to do?
3. Is there another way they’re already doing this?

If you’re constantly asking these 3 questions, you’ll have a much more successful and efficient design and development process. There are a number of specific advantages to keeping the user in mind while working and I list some of the big ones below.

Faster design iteration

Question 1 and 2 mentioned above are pivotal to creating a fast design process that has a clear goal. The clear goal is the important part of that sentence. I’m guilty just as much as anyone as starting a feature and just going with the flow of it and making it “better” as I go along. But is it better for my user? What are the key targets I’m trying to hit by adding this feature? How do I know which features are necessary and which are just a waste of time (even if they’re nice to have). How do I even know I’ve actually hit my goal?

We take for granted that we answer these questions instinctively and with our subconscious instead of laying out clear goals and metrics.

Having a clear answer for “Who is my user?” and “What are they trying to do?” gives you immediate feedback. When you’re working through features and wondering “do I need this one little extra addition just incase the user tries to do _____”, you can refer back to your answers. You’ll be surpised to find that most of the time the answer to that question is actually “No.”

Reduced bugs

Another big advantage I find with keeping users in mind is that I build much simpler software. Left to my own devices I end up making features to catch edge case after edge case. Along the process, I find that I lose a clear picture of who the user is because I have so many edge cases in mind, that the user could be anyone! I continue to add feature after feature and then my software becomes bloated and complex. Complex software that isn’t planned in advanced can also be riddled with hard-to-track bugs, and worse, bugs that you probably won’t catch on your own. These will be weird issues that users will find and will be turned off by. Keeping in mind question 2 and 3 can help reduce complexity and bugs.

If I’m constantly asking myself “What is my user trying to do?”, I keep a straight path towards finishing development. I know my targets, and I don’t stray for random features that come to mind, because when I think “Is my user actually trying to do that?” the answer is often “No, but I thought of it because I’m a developer.” Just because it came to your mind at one point, it doesn’t mean it needs to be included as a feature.

Asking yourself “Is there another way they’re already doing this?” keeps you informed on competition but also on workflows that the user may already be used to. If there’s already a predefined way of doing something, you can use that as a base to create software that will be familiar by the user and in a sense, tested by users. Bugs can often be introduced because of weird logical workflows we setup. Building on that base of existing workflows or software design can help weed out weird design logic and help you stick with what works. This time you won’t spend developing something weird helps keep your code free of strange bugs.

Higher user satisfaction

User satisfaction is often the correlation between the user’s problem and your problem. If the two line up, and you spend the time to build software that solves your problem, you’ll have a satisfied user. The issue in reality is that developers have a skewed and often very fine-tuned sense of problems and solutions. These senses can vary greatly from one developer to another (i.e. why we have so many “standard protocols”) and can differ heavily from the general public. Something you might think is completely logical might be confusing to a regular tech user.

But how can you be sure your users are actually satisfied and are receiving their solution? One way is to continuously ask users. This methods of active user testing is quite valuable but it can be time consuming and expensive. If you’re designing from the users point of view from the beginning, you can bypass a few user testing iterations. This is where all three of the questions outlined can improve your development process.

Having a clear sense of the user allows you to really think like them when you’re developing. This may sound silly but just working while thinking like the user influences design decisions as well as feature builds in a way that makes your software more approachable by the user.

The ultimate goal of software development is that you’re trying to help the user do something. By asking “What is my user trying to do?”, you know exactly what “do” is. This keeps your design and development focused and your user will feel that when they find your software intuitive, straight forward, and easy to use. I always forget that people really just love simple software that solves the one thing they were having trouble with. They really don’t want my nonsense and feature bloated catch-all tools.

As mentioned above, knowing how a user may already be familiar with the problem/solution is important. In some cases you may want to introduce a completely novel solution, but in other cases, you’ll be porting/improving upon existing workflows. It’s silly to think that you can accidentally make out-of-left-field novel software when you’re trying to improve on common workflows, but if you’re not careful and keeping yourself in check, it’s easy to slowly drift over days, weeks, or months and end up really far away from a simple workflow improvement. Keeping in mind what the user might already be doing and what other similar softwares are doing helps you to avoid drifting away from your goal.

Wrap up

Next time you’re designing a piece of software, a UI, an experience, or a feature, take time at the start to define your user. Really imagine who they are and how they normally interact with software and apps. Ask yourself (as the user) what your goal really is and what you’re trying to achieve by using this new tool. Dive deeper and figure out how they may already be solving their problem with other make-shift solutions. The time you spend thinking as the user and internalizing their wants, needs, and struggle, is time spent creating more robust software on faster timelines with fewer bugs. For something so easy to do, it has clear benefits!