User Centric Design Essentials

Hey, how are you doing? On to one of my most favourite topics, user stories and user centric design.

• What are user centric design essentials?

• Why is starting from the perspective of the user a good thing?

• What is a user story and what makes a good one?

• Why do we need to write user stories and acceptance criteria ?

Let's get into it below and answer these questions.

What are user centric design essentials?

User centric design is a term that was first coined by Rob Kling in 1977 in his paper "The organizational context of user-centered software designs", in this paper he discussed how the organizational environment significantly influences software design, particularly when aiming for user-centered approaches. The key takeaway is that creating software that genuinely meets users' needs isn't just about good design practices; it requires understanding and navigating the organizational context in which the software is developed.

This includes factors like company culture, management structures, and communication flows, all of which can either support or hinder the implementation of user-centered design principles.

TL;DR Essentially, it's a reminder that the broader organizational landscape plays a crucial role in determining the success of user-centered software projects.

For the product we are building we need to pose questions to the client to get them to connect, not only with the future product, but their processes, their feelings and emotions and also to us as consultants on a project.

Why is starting from the perspective of the user a good thing?

This might be obvious, but making assumptions is never a good thing. Starting from the perspective of the user or client, is the best way to ensure the all parts of the project team are on the same page. We want to be able to empathise with the client, we want them to walk us through their pain points, frustrations and what motivates them through their goals. What makes them happy ? What makes them sad? Sometimes these questions can be difficult to ask and answer, but it drives the project forward in the correct way because empathy and user perspective is at the heart of everything we do.

Topics to touch on and to include to ask include, but not limited to:

Background and Demographics

• Personal Background:(Brief history, education, family)

• Professional Background:(Career path, current job, work experience)

• Daily Routine:(Typical day in their life, from morning to night)

Goals and Motivations

• Primary Goals:(What they want to achieve in their personal and professional life)

• Secondary Goals:(Other goals that are important to them)

• Motivations:(What drives them to achieve these goals)

Challenges and Pain Points

• Primary Challenges:(Main obstacles they face in achieving their goals)

• Secondary Challenges:(Additional difficulties they encounter)

• Pain Points:(Specific problems they experience in their daily life or work)

Behaviours and Attitudes

• Tech Savviness:(Their level of comfort with technology)

• Information Sources:(Where they get their news and information)

• Buying Behavior:(How they make purchasing decisions)

• Attitudes:(Their views on work, life, technology, etc.)

Psychographics

• Values and Beliefs:(Core beliefs and values that influence their behavior)

• Interests and Hobbies:(What they enjoy doing in their free time)

• Lifestyle:(How they spend their time outside of work)

• Personality Traits:(Key characteristics, e.g., introverted/extroverted, analytical/emotional)

Feelings and Emotions

• Frustrations:(What makes them upset or frustrated in their daily life)

• Fears:(What they are afraid of or anxious about)

• Happiness:(What brings them joy and satisfaction)

• Aspiration:(What they aspire to be or achieve in the future)

Experience with Your Product/Service

• Usage Patterns:(How they use your product/service, frequency, and context)

• Satisfaction Level:(How satisfied they are with your product/service)

• Feedback:(Comments or suggestions they have about your product/service)

• Improvements:(What changes they would like to see)

Scenarios

• Day-in-the-Life Scenario:(Detailed description of a day in their life, highlighting how your product/service fits into their routine)

• Problem-Solving Scenario:(A specific situation where they encounter a problem that your product/service helps to solve)

• Goal Achievement Scenario:(How they use your product/service to achieve a particular goal)

Imagine having all of this information at your fingertips when you go to build a product for the client. Everything you do moving forward will be able to be mapped back in this Q&A session in some way.

What is a user story and what makes a good one?

On to the juicy bit. I LOVE writing user stories, I always have done. I just love how they flow, when you get your groove on.

As we have explained above, user centric design is imperative to user adoption and a succesful product, but how do we articulate that so that we (project team, developers, product owners and the client) are all on the same page?

Well, this is where user stories come in.

A user story, as it's name suggests, is written from the perspective of the user.

Their structure is usually the same (I can get quite pedantic about this) and they look like this

As a <persona>, I want to <function>, so that <business value>.

Let's break that down.

The persona is the user type that has been defined in your user centric design questions. This could be for example a finance manager, an HR representative, a police officer. Obviously it depends on the project.

The function is what you want to achieve in delivering this user story, so for example let's look at the day in the life of me being a Dad:

(this should be interesting haha).

As a Dad, I want to ensure that I have a well planned summer holiday, so that my children don't get bored and I loose the will.

Now, yes, it is a bit tongue in cheek. But here I have defined the persona (me, Dad), the function (to be able to plan my summer holiday with the kids) and the benefit is that everyone knows what we are doing and hopefully the kids won't get bored in the process.

As you can see, we are writing it from the Dad persona perspective. This gives you an idea of how a user story could be written.

Let's now look at an example inside a Power Platform project, I will be using an example of building a solution for a Nursery business looking after pre-school children.

As a parent, I want to be able to onboard my child to the nursery, so that I can provide pertinent details about their date of birth, allergies, special educational needs.

So we have identified the persona, in this case the parent. They want to be able to provide some detail of their child that is starting nursery to ensure that the nursery business has all the information they need.

What is really important here is not to go down the technical route, notice how I have not talked about how they are going to do this, just the what and the why.

As a power platform consultant, I can take this away and start to work out what I need to build to be able to support the completion of that user story.

A good user story is something that is deliverable. In Sprint Planning sessions, you should be going through each user story and making sure it isn't too big and it's not too small, and that it is deliverable. Everyone from the product owner, to the subject matter expert, to the solution architect and Power Platform consultant, should all be in agreement that the story can be delivered.

Why do we need to write user stories and acceptance criteria ?

Acceptance criteria is important. It is important because it allows the user story to be tested. This means that the acceptance criteria must be answered true or false. This allows the users of the system to be able to go through this as a kind of checklist to ensure that he user story has been developed correctly.

One popular method of writing user stories is the gherkin method, Given, When, Then, And, and below are some examples, each scenario could actually be a task associated with the parent user story.

Scenario: Parent enters child's date of birth

Given I am on the child onboarding page

When I input the date of birth using the date picker or manually enter the date

Then the date must be validated to ensure it is in the correct format and not in the future

And I should see an error message if the date is invalid

Scenario: Parent provides allergy information

Given I am on the child onboarding page

When I am asked to enter allergy information

Then I should see a text field to input allergy details

And I should be able to enter multiple allergies

And I should have the option to indicate that there are no known allergies

Scenario: Parent provides special educational needs (SEN) details

Given I am on the child onboarding page

When I am asked to enter special educational needs information

Then I should see options to specify common SEN categories and a text field for additional details

And I must be able to provide detailed descriptions of my child's SEN

Scenario: Parent reviews and confirms the onboarding details

Given I have entered all required information about my child

When I reach the summary screen

Then I should see a review of all the information I have entered

And I should be able to edit any section before finalizing the onboarding process

Scenario: Data security during submission

Given I have finalized the onboarding process

When I submit the information

Then the data must be securely transmitted and stored using industry-standard encryption

Scenario: Parent receives confirmation of successful onboarding

Given I have submitted my child's onboarding information

Then I should receive a confirmation email summarizing the entered information

And the email should provide contact information for further inquiries

As you can see, all of these have a true or false outcome.

I hope this helps you in understanding what a user centric approach is and how to write good user stories.

Thanks for reading.