User Point of View vs. System Point of View Copy

Yes, it’s all about the user and customer point of view!

I know many of you work within deep knowledge of systems and applications, and you may model the system flow or system process often.

It is SO important in analysis that we FIRST understand the user point of view.  We build systems to help users do things!  We need to understand what we are trying to help them do before getting into the details of the technology. Think about it like this: What would the basic process be if there wasn’t a system in place?  How would it be done? I like to think of it like that old cartoon The Flintstones. How would Barney and Wilma need to do it?  Well, to get a loan from a bank, they didn’t have websites, or mobile devices to do that; they would need to walk into the bank.  Then the process might look something like:  Provide Personal Information –> Wait for Approval –>Sign Documents –> Get  Loan Funds.  These 4 simple steps happen no matter if it’s in person filling out paper forms, on a website, or on a mobile/digital device. The difference is the technology enabling the process. Once you have this from a user point of view, you can innovate any way you would like!!!

This is the magic of process modeling! You define the user steps (agnostic of technology) first, then you can dig into the rules (also agnostic of technology), and these rules are a lot of the process details. For example: The rules for what data is required when a customer is providing their personal information are likely the same rules no matter if it’s in person or on a mobile device.  Same for the approval rules….

The problem comes when we, the team, and stakeholders define them in terms of technology and systems. We get constrained by our own thoughts and processes.  We end up seeing the solution and the customer experience in a very narrow view point, causing sub par results.   We need to eventually get to those technical details, but it’s a mistake to start there before we truly understand the problem to solve, the process and the details agnostic of the technology.

Let’s look at the loan example again: Provide Personal Information –> Wait for Approval –>Sign Documents –> Get Loan Funds

We want to avoid missing key requirements by not defining the process by the technology. For example, using screen names, or using language like “click on”, or “screen”….the future may not be a screen, a click, or the same system… those are not the user needs. The user needs are the meaningful verbs that describe the user action agnostic of what the technical design is. You can always layer over or onto the base process model with the technical implementation of how the action will be enabled by the technology!

For example:

  • Provide Personal Information (on our online application form on the website)
  • Wait for Approval (Send via text and email, as well as updated on the application form online)
  • Sign Documents (eSignatures on website)
  • Get Loan Funds (automatically deposited into users account listed on the application)

What a difference plain language makes!

When working with our business partners and customers, we want to work with the user/customer point of view. This is the lens they often are thinking in as well, and it will bring out more requirements gaps and deeper conversation.

So, what if you work on a team that supports the backend, API, database, or a package/cloud software? Does this still apply?  Absolutely, yes!

  • Backend Systems – They support user processes and impact the user experience, so we can’t implement and design the correct details without understanding the higher level user process and user goals.
  • APIs – They also support user processes and impact the user experience, so we can’t implement and design the correct details without understanding the higher level user process and user goals.  Ask yourself – What would happen if this API was not in place?  What would happen to the user when they try to _______?
  • Databases – The data is very important to the user experience, if they see the wrong data, then they act on the wrong data or simply ignore the process all together and find themselves a workaround. So, we must understand the user’s perspective to select the correct data to display, store, compare and report on.
  • Package/Cloud software – These systems are built on proven user processes and it is critical to dig in and understand what the assumed user process is that the package is enabling!

Okay, so remember, the user point of view is an enabler to innovation! Without it, you are likely going to be very busy with enhancements and defects to get to user satisfaction. Your stakeholders likely assume you understand the user point of view!

Ok, let’s try something out!

What would the process be for ordering a pizza?  Think about what the process is if you are walking into a pizza shop, calling in an order, ordering online via the website, or from your mobile phone.

Take a few minutes to think through this and draw it out.

The quiz that follows will ask for your answer.