"I've solved this problem before."

"I need to sort out the technical requirements first…"

"I've already implemented the following…"

If you ever hear someone utter phrases like these at the start of a project, chances are you are in for a world of trouble.

It's not that knowledge of a problem domain, determining technical requirements, or getting a head start on solving a challenging technical problem are so inherently bad. The cardinal sin is focusing on any of these before you have sorted out the most important thing of all: the user experience.

Now, I'd be remiss if I didn't take a moment to define what I mean by user experience (somewhere, Louie Mantia is probably pleased by this aside). I don't consider specific visual treatments, textures, colors, button-styles, text or anything else related to the visual design of the application to be the core part of the user experience. Sure, you could argue that "how it looks" contributes to what the user experiences, but I prefer a much more narrow definition: What are the core features of the app, how are they organized, how do they work, and how do they flow together to create a cohesive workflow or journey through the app itself? Put another way — the user experience is the essence of how the app works and how it solves its core problem. Thus, it can be visually styled in any number of ways after that core essence is understood. For the sake of argument, I'll assume this definition of user experience for the rest of the post.

As much as the specific visual design might be separable from the core user experience, the underlying engineering is not separable from the core experience. Yes, we live in the world of MVC and if you are doing things right you are maintaining a reasonable delineation between the underlying business logic of your app and how your app actually behaves. At the same time, anyone with real combat drops can tell you that the core user experience absolutely has an impact on how you choose to technically solve a problem and much of the code you write. Sure you may have some data structures and model controllers that remain the same, but built on top of this raw data are workflows and processing that are fundamental to how you solve your specific problem. Some of these controllers dabble in data, many others will be specifically tailored to the flow, organization, and processing of the data in your application. If you chose a different core experience to your app, you would likely write a very different app than otherwise.

So far this has seemed pretty academic, so why is it that the quotes above are such a problem? They all belie a common problem in our industry — putting the cart before the horse. As I talked about in my last post, the art of building a great product is solving a need in a delightful, thoughtful, and simple way. The last two elements of this, thoughtful and simple, require lots of energy, discussion, iterating, throwing away, starting again, and reshaping how you approach a problem. If you rush ahead and start planning how you will technically solve a problem, or laying the ground work for user flows and functional architecture, you are already shackling yourself to a specific world view and a specific solution set. The best applications and products rise above the rest because they spend their blood, sweat, and tears figuring out how to break the constraints of their peerage of existing solutions.

If you want to build fresh, thoughtful, or revolutionary products you need to not put constraints on yourself from the start. You need the latitude to (*jargon alert*) think outside the box and see the problem space with a fresh perspective. What are your users really trying to accomplish? What is the real essence of their problem? How have others approached solving this and how does their approach work or not work? Think about your user's real goal in using your software. Why should their end goal be limited by any particular technical constraint or mode of operation? Why should they have to create a login? Why should they have to organize the content themselves? Why can't you automatically do a task for them? Why?

Focus on the user. Focus on their life, their problems, and how you are helping them. Put down that database, put down that web server, put down that Core Data model and think. No, this step doesn't involve code. Yes, for many of you this will feel foreign and scary, but focusing on the user is liberating. It frees you from your technical shackles and puts the world in real perspective. Your focus becomes the things that matter, the things that change people's lives. Technology is a hindrance when it doesn't get out of the way. Technology is a hindrance when it becomes the point, as opposed to the human experiences we are trying to improve.

Focus on the user from the start. Focus on the user before you ever write a line of code. Let this principle guide you along the way and never forget that focus.