What is Prototyping?

What is prototyping?

Prototyping is a way of visually explaining an idea. Sometimes, it is a way of visualizing a wild and crazy future, like what is often seen at auto and fashion shows. But, in the world of software, it is a tool used to provide guidance and get feedback from the users. At its essence, prototyping is a stripped down interface, focused on the experience of the user (User Experience, or UX).

1. No consideration has been put into designing an interface, not even an MS Paint mock-up. Someone made the decision to use a framework like Bootstrap, Material UI, etc. A developer, who has experience with user interface development, steps up and starts coding. X number of hours/days/weeks later, there is enough to demo for the first time. The users are there to review what is to be expected only to be completely let down. In their minds, they had a completely different vision. No one knew this, because no one asked.
2. A graphic designer is hired to work with users on an interface. It’s imperative that the interface fits the design and marketing of the company’s established style guide. That basic interface “style guide” is handed off to the developers and they try their best to translate the business requirements into the design set in front of them. They keep having to go back to the graphic designer to get approval for certain tweaks. The designer figures out how to make the tweaks work within the guidelines, but must now get user sign-off. This loop can quickly turn into what feels like an infinite loop.

Prototyping avoids these pitfalls by allowing designers to focus on basic wireframes that demonstrate a page, or component’s, layout, content, and expected behaviors.

• input format (email/phone/URL/etc) requirements?
• What fields are required?
• What happens when a required field is missing?
• What happens when the user clicks Save?
• What happens when the user clicks Cancel?
• What happens when there is an error returned from the server?

Oftentimes, these questions go unanswered. The developers will usually need to solve these problems on their own based on previous development projects, or based on their own opinion on what's best. What happens a lot of the time, however, is the developers are forced to go back to the users. This starts to build into an endless list of: “While I have you here, I was wondering if we could change this?” requests.

There are flaws with this approach, obviously.

These ways of approaching projects ignore the business requirements of the application. Business requirements are the requirements that can not be ignored, because they are requirements set forth by your business, and they are always unique to every project. Sure, some projects might be extremely similar, but there is always a slight variation somewhere, always.

Again, this is where prototyping comes into play. Prototyping can help flesh out these potential problems, or shine a light on issues that would have otherwise been missed.

Who Knows Better Than the User?
Users are the people who will actually be using the system. Users know their workflow. They know what they do, and how they do it because they do it every single day. Without their input, there can be a lot of assumptions about the requirements. Those assumptions can be incorrect and oftentimes are.

A lot of people worry about having users in the room when talking about software design. But, when it comes to the user interface and experience, they are vital. Yes, they can make a lot of requests, but that’s fine. Within those requests can be little insights into how to improve their workflow. Those improvements can lead to some pretty decent increases in productivity, either through employee satisfaction or through a reduction in time spent on the task at hand.

Prototyping allows everyone to provide feedback in a constructive way that can help lead the way to increases in productivity.

• I find that working with the users on a project like this always yields me better results when I need to change things on them. Sometimes old workflows aren’t the most efficient. If users are suddenly shown an application that will completely change their workflow, or even moderately change it, they will usually be more reluctant to adopt it. Working with them, and allowing them to discover these benefits with everyone, can lead to a much smoother adoption rate.
• The prototype can be used to provide feedback from the user before coding begins.
• The prototype can be used to provide pre-training. Users can be given demonstrations so they can visually understand the changes before they occur.
• Project/Development Managers can more accurately layout the project tasks and timeline, reducing missed deadlines, overtime, etc.
• Developers can visually see what is expected of each component they are responsible for. Not only visually understand it, but functionally as well. Knowing how components should function ahead of time is very valuable for developers.
• Because the developers know each component's expected behavior and functionality, there will be less back and forth between the development, QA team, and UAT.