Save Yourself a Headache: Identify User Requirements Before Implementation.

You waste a lot of time and money if you don’t work out the user and design requirements of your digital product before you begin implementing it.

Let me explain why.

When going through development, it is easy for engineers and designers to misunderstand the needs or intentions of the end-user — especially if the processes for eliciting requirements is hastily done.

Sure, designers may possess experience with UX best practices, but this isn’t always enough to guarantee a successful design from the user’s perspective.

And, yeah, software developers can throw together an interface based on what they think is needed. Perhaps they’ll base it on previous experience, and it’ll at least get the job done.

But both of these options leave a wide-open window for guesswork and errors. When there is a complete disconnect from those who will be using your prescribed product on a day-to-day basis, it is likely you will be doing a lot of revising.

So, how do you avoid this?

This is why it is important to have a discovery process to identify and understand the primary motives and intentions of the end-user. It is this understanding, combined with your skill as a developer, that leads to defined solutions for the various problems that your user is trying to solve.

Flow and functionality are more clearly understood, leading to simplified functional requirements and, most importantly, better-planned user experiences. Without it, you could be left with a failed or ineffective design that struggles to solve the user’s problems, incurring an unnecessary overhead in development.

Let me give you an example.

I had previously been working on a project in which we were developing a data management system for location services purposes. This application was intended to be used by IT technicians in order to manage hardware, system settings, and diagnostics across a given venue.

Had I worked on a product like this before? Nope. But two of our team’s senior developers had worked on something similar in the past. I was brought on as the resident front-end developer to build the UI and functionality of the client-facing portion of the application.

My expectation was that I would be working with a design team to implement fully fleshed-out user flows. This wasn’t exactly the case.

We started out with a few basic wireframes of the main UI and navigation , as well as a couple of views featuring tables for some of the known data entities. The rest of the UI requirements came from our lead developers as well as some requests laid out in an RFC document (not exactly helpful from a UX perspective).

For the most part, it went like this: “We need this view to have A, B, C, and when you click b, you should be able to see and edit x, y, z.”

This would lead to me asking a lot more questions, like, “Why would I do this? What am I trying to accomplish here?”

Without understanding the intent from the user’s point of view, creating an optimal design was going to be difficult. I had to defer to my leads as users; partially because, at this point, they were the users, though not the end-users. And without design iterations, I would have to fill in the blanks myself. This lead to me throwing something over the fence, and watching it fly back. And then repeating the process.

When testing and deployment came, real-world usage revealed how some of the UI flows were cumbersome or less practical than anticipated. This resulted in several revisions to the implementation and extra time spent in QA. Had we spent a little more time in design and review, we could have spent fewer dev-cycles trying get certain features right.

What I learned from our problem.

So what did I gain from this experience? For one, I asked a lot more questions and got better at asking the right ones that would help me relate to what the user (or pseudo-user in this case) was trying to accomplish. Using that understanding, I could better envision the arrangement of UI elements and more practical user flows. This greatly cut down on my time spent in implementation and testing.

I also got some experience as a designer, putting together designs as new features were being planned out. Sure, I’m not the greatest designer, but taking the time to conceptualize things before coding has been a great help toward getting things right early on. And I have a much better appreciation and interest in the design process; it’s nice to be able to take part in driving creative input.

What you should learn from our experience.

Is it possible to avoid this situation entirely? Most likely, no. There will always be iterative cycles in which improvements must be made.

Can it be mitigated? Absolutely. Taking the time to work with end-users to generate fully fleshed requirements can allow a designer or engineer to better understand the problem and provide a much cleaner solution.

Even if developers are standing in for the end-user, more thorough design reviews can help narrow down an implementation closer to the mark earlier on. As a result, you’ll exhaust less effort in development. That’s less time spent in coding, QA, and bug fixes. Your implementation will be better planned and easier to trace through. More importantly, you’ll arrive at more frictionless flows, improving the overall user experience.