1. On scoping: or “Should we meet this need?”

• Do people want it? (Search, Traffic or behavioral evidence)
• Can only the government meet this need?
• Is it in line with digital by default?
• Can people reasonably expect that the government should meet this need?

2. On Usability and Design standards: Make sure users succeed first-time.

Why we care more about effectiveness than efficiency or satisfaction

• They achieved the outcome they expected: “short answer is that a service is usable if the people who need it can use it to get the right outcome for them.”

“And if auto-tabbing stops just a few people from using a service successfully, their needs take priority over the many people who might prefer but don’t need the feature.

Effectiveness for all users takes priority over efficiency or satisfaction for some users.”

3. On Service standard 3: Simplicity

• Digital Service Standard (pre-July 2019)
• 4. Make the service simple to use

“It costs the government time and money to deal with mistakes that happen when services don’t work well. And making things more complicated than they need to be undermines trust.”

- show the majority of users of your service are succeeding the first time they try to use it

- explain all end-to-end user journeys, including assisted digital journeys, demonstrate that they work and how you tested them

- explain how you’ve designed your assisted digital support model to meet user needs and how you’re providing it – if you’re not providing it by telephone, face-to-face, talk through and on-behalf-of, you must explain why

- explain how your assisted digital support will be sustainably funded and free to users

At the beta and live assessments you also need to:

show how most people can get through the service end-to-end without assistance

- explain what you learned by testing your assisted digital support model (the way you plan to help people who lack the skills, confidence or internet access to complete the service on their own)

- explain how you’ve changed the interface design in response to usability testing, showing your build, measure, and learn cycles, the hypotheses you tested, what happened and how you reacted

explain how you’ve done usability testing, including users with the lowest level of digital skills

- explain how you’ve tested your assisted digital support model

- discuss whether your usability testing included the supporting content and proposed start page for the service

- explain how you tested whether the name of your service makes sense to your users

4. On Service standard 2: Solve a whole problem

2. Solve a whole problem for users

“Fragmented services are difficult to use, because users have to do the hard work to make sure they’re doing what’s expected of them….choosing the right form to fill in out of several near-identical options.

And it does not mean trying to fix everything at once. Start small, and deliver value to users incrementally and frequently.

Just make sure the increments are part of a plan to bring related content and transactions together into a journey that makes sense to users, irrespective of which organisation they ‘belong’ to. Because users should not have to understand how government works in order to use public services.”

Service teams should:

- consider alternatives to creating a service – for example publishing website content, running a campaign, partnering with a non-government organisation or making data or an API available to third parties

- understand any genuine constraints that affect the service – for example, legislative constraints – and work with policy professionals to solve any problems those constraints are causing

- make sure services are scoped according to how users think - not too narrow or too broad

- be able to explain how the transaction they’re working on will join up with other things into a journey that solves a whole problem for users

- take responsibility for agreeing how this user journey will work with organisations responsible for different parts of it – for example, with the GDS content team to join up ‘mainstream’ GOV.UK content with the transaction you’re working on

- work in the open so that people outside the organisation know what they’re doing – increasing the potential for collaboration and reducing duplication of effort (for example by publishing business cases, mission statements, research findings, user experience maps, maps of existing services and product roadmaps showing plans to develop new features)

- work towards minimising the number of times users are to provide the same information to government (while respecting users’ privacy)

- work across organisational boundaries where that’s necessary to solve a whole problem for users

5. On scope: Right-sizing

• Getting the scope of your transaction right

“If you scope your transaction too broadly or try to make it do too many things, it won’t be obvious what problem it’s solving. And users won’t be able to get straight to the task they need to complete.

If the scope is too narrow, the transaction won’t fully solve the user’s problem, meaning they don’t get the outcome they need.”

So start with one transaction per task. And only bring tasks together into a single transaction if:

- you see in research that users think of a group of tasks as part of the same thing, even though government sees them as separate

- you can’t solve a recognisable problem without bringing them together into one transaction

6. How to know you have a “whole problem”

Map and understand a user's whole problem

“For instance, booking a theory test is just one part of learning to drive a car.

For users to complete complicated tasks like these successfully, all the different parts of the journey need to join up coherently. If they don’t, the user will get stuck and their journey breaks down.

To build things that join up coherently, teams need to understand what the user’s wider journey looks like. It’s probably not reasonable to expect individual delivery teams to build a detailed understanding of that themselves.”

- Work out who else is involved in delivering a user journey

- Map user journeys together

- You want everyone involved in delivering the user journey to have the same understanding of what needs fixing

- Work out:

- dead ends in the user journey

- users not understanding whether they should use a particular transaction, or which one of several similar looking transactions they should use

- confusing or duplicative content

- online and offline elements of the transaction not joining up in an intuitive way

Identify the quicker wins

Start by fixing the stuff that’s cheaper and quicker to fix, so that you improve some things for users straight away.

Show what bigger improvements might look like

As well as quick fixes, you’ll probably spot opportunities to make bigger improvements, or redesign elements of the user journey.

For example, you might see in research that users are confused because something they think of as a single task is spread across several transactions – and that it’d be more user-centred to bring them together into one transaction.

Or you might see that the journey’s breaking down when the user moves between channels and that slightly tweaking a letter makes it easier for the user to continue their journey online.

You can build an improved journey map that includes improvements like these and shows what the ideal user journey would look like.

It doesn’t need to be polished: it just needs to show how the journey might look if it was designed around what makes sense to users, rather than what makes sense to government.

7. Service mapping: the map of a process

How we approached service mapping

- primary tasks all users need to do to complete the journey (for example, take a driving test)

- secondary tasks that some users might need to do (for example, complain about a driving instructor)

- guidance or context around how to do the secondary or primary tasks (for example, the ‘Theory test: cars’ guide)

8. User journey mapping: The end-user perspective

Why we use user journey maps in government

“A user journey map is a way of showing a user’s journey through a service over time. It may include many transactions and different services. It starts where a user’s need for that service arises, and ends at the point where they stop using the service. “

9. Concrete case

Mapping services for the Ministry of Justice

In essence, it is a map of the business process flow and decision points for the user, including: particular qualities, problems, requirements and outcomes.

we used the maps to plot user pain points. As a part of our research we met with frontline staff and support groups we conducted interviews we then mapped the pain points we found from this research.

We coded each user issue with a number and colour (red for behavioural issues, green for process issues and yellow for forms and related materials). By placing sticky dots (with the issue number) for each problem on the map we could see visually that many problems were either common across the whole process and across multiple claim types or happened before the claim process even began.

volumes of users

10. On Service standard 3: Services are joined-up

3. Provide a joined up experience across all channels

“Bringing different channels together means you can design an experience that makes sense to the user, however they use the service. Users should not be excluded or have an inferior experience because they lack access to technology or the skills to use it.

People working on the service are empowered to fix problems in whatever channel they crop up, instead of having to create work-arounds. ”

- the service team is empowered to find the best way of solving the problem

- front line operations staff and policy people are invited to attend user research and to contribute to prioritisation decisions

- designers and user researchers are working with front line operations staff

- data and user research on the online part of the service is used to improve offline channels, and the other way around

- front line operations staff who are responsible for answering users’ questions know how the online service works, and there’s a process for keeping them up to date with changes

- they’re working with colleagues in operations to understand how changes to the online part of the service will affect offline channels, and vice versa

- plans to increase digital take up do not involve making it more difficult to find details of phone, paper or face to face channels

Service teams should be able to identify any problems with internal processes, systems or structures that make it more difficult than it needs to be to design and operate a joined up service.

And show that there’s a plan to fix them – for example, by having an agreed procedure for resolving issues with the online service that are causing problems for the offline channels. Or the other way around.

they are testing and can make changes to users’ experience of both online and offline channels (for example, call centre scripts and letters)

11. Introduction to standards

Designing good government services: an introduction

- from beginning to end – think about every single thing a user needs to do, including anything done by a supplier external to government

- from front to back – this means both the service that users see and the internal processes, software and policies behind it

- across every channel – phone, post and face to face as well as digital

A user can do what they need to do, from start to finish

A user has to do as few things as possible

There are no dead ends

Internal structures are not shown to users

It’s straightforward to get human assistance

The service is clear, and easy to find

12. Mandatory service measures

Data you must publish

What to include as a transaction

A transaction is an exchange of:

- money

- information

- permission

- goods or services

Transactions on your service will have clearly defined start and end points. They will also result in a change to a government system, eg someone’s personal information or the details of an interaction are stored in a register or database.

The following activities do not have clearly defined start and end points and are not recorded in a government system, so they are not transactions:

- general advice or enquiries

- informal complaints

- visits to websites

When a transaction is completed

A transaction is completed when someone finishes the task that your digital service provides. For example, when a user:

- submits an application

- makes a payment

- makes a booking

The service should tell the user that the transaction is complete with a confirmation or ‘thank you’ message.

13. Calculating upsides of building a digital service

Measuring the benefits of your service

14. Accessibility with internal persona walkthroughs

Using persona profiles to test accessibility

The most useful GDS entries in my life, at the moment was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Smiling.

The key difference between me-facilitating-group-design-sessions now, and me-facilitating-group-design-sessions circa 2011–2012, is smiling.

Let me just say that it’s a totally different (more improved) vibe. Yes, design sessions aren’t geared to be “happy”. That isn’t the goal. But, I was also a more neurotic process facilitator in 2011. I can observe (through the design session results) that my older facilitation approach didn’t help.

Laughing helps.

As a female corporate employee, laughing during leading a group session helps. (Yes, I am going to start sounding awfully sexist in the next statements, and I’ll potentially draw a lot of head-shaking, but – tough luck – I’m a woman, and this is my actual experience in my working life.)

Imagine leading an ideation session as a stern, straight-faced female – as opposed to a jolly woman (This could also apply to men, but I’ve seen stern men lead design sessions with no problem. I have yet to see a strict, stern woman lead a successful design session here in the Philippines).

Sternness doesn’t help group facilitation in general (regardless of gender); and I expect that it definitely does not fly with large groups of older working men to be led by a stern woman with no sense of humor.

Un-fun

In the earlier part of my career – I was definitely un-fun during times I needed to lead group design work. I was serious, and would issue commands. I now see why I just earned a lot of “ire” from internal clients I wanted to help. I sounded more like a drill sergeant than a collaborator.

My long-time teammate also added two additional dimensions – I also was very strict about process then (“This is how it should be done.” “This is what the research said.”), and now he mentions I’m more forgiving and flexible.

I was never a programmed facilitator – more of a fly-by-the-seat-of-my-pants type. But, my many years in market research before jumping into experience design gave me a very strict intuition of what works for people, and I was very, very transparent – and forceful – about it at 28 years old.

I have more “give” now, at 35 years old; I understand that you can’t bludgeon people with data into submission, and have to be willing to let ideas through – even without research.

He also added that there is also an external factor I shouldn’t discount – culture fit. We worked at a very different corporation, with a very different corporate “personality” at that time. So, yes, as much as I believe good facilitation travels well – some corporate entities are harder to work with than others, depending on the skills and values it actually rewards:

e.g. What gets people promoted at a company? A get-it-done-right mindset and habits? Or freewheeling creative ideation and political charisma?

Okay, even without me being female, and just about team dynamics, in general: regardless of gender, the ability to laugh (and laugh at oneself) adds warmth and lightness to sessions meant to foster collaboration. Again, not that “lightness” is the goal in and of itself, but is a good conduit. Lightness that should come from a place of humanity – of acknowledging that you are a person talking to people, real individuals.

I have the slight advantage of years of doing research on character development for TV, movies and music – but I believe many others have officially called this out.

For that, I leave with you with the ever-popular Brene Brown talk, on vulnerability:

On Smiling, Sex (i.e. gender) and Successful Design Facilitation was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Weeknote #10

On Product Managers

The best product managers I’ve seen at work have this similar look when they’re encountering and observing user data. You can almost detect how intent they are on understanding which ones are the core problems they need to help users with. Just amazing to observe.

Shout out to Alice Newton-Rex, John Veevers and (even if your formal title isn’t “product manager”), Eva Keyes, Jennifer O’ Raw and Danielle Garcia.

On Explaining and Teaching Qualitative Research

1. Defining what makes a good qualitative researcher

People who aren’t formally trained probably do not get the privilege to see that qualitative research is such an individual thing. Or maybe just the way that I was trained and taught.

So, things I’ve been learning (to teach):

The way that I believe in doing qualitative research may be a bit unorthodox, or goes against the grain of classic teaching – but! Was validated by a clinical psychologist who trained our team – authenticity is part of facilitating.

I don’t think I can conduct research in a way that isn’t true to myself. Some people have great pokerfaces. Some people are warm and empathic. I’m a giddy, jolly interviewer. It’s just the way I work and react to people. I’ve had to work around it of course. Just ask me how if we ever meet up.

2. So, I was asked, how do you know what an excellent qual researcher is if everyone’s different?

Well, that’s where performance objectives come in. Does your company value clarity? Does your company value meeting business goals? Storytelling? Business impact? Depth and thoroughness?

Then, that’s how you know the research person is good.

3. Also had a discussion on handling creepy men in interviews.

My take on it: it’s still a corporate project activity. You have the right to set ground rules for personal comfort, if it’s getting too creepy.

On alignment

I need to remember and be more thoughtful about how not everyone is well-versed with how a research project works. Therefore, pre-plan the team briefing. You can’t keep doing things on the fly, even if that’s what you like.

Not everyone is aware of the best practices of confidentiality and data ownership in corporate research. This is something you need to educate people on, not assume.

On still being surprised after all these years.

You can have over 12 contextual inquiries for one straightforward service, and see a unique use case in each one.

On ROI.

In the hands of a sincere, open-minded, intelligent product team, exploratory research is expensive to run, but worth every moment.

On car rentals

Canvass early.

Weeknote: Research Work with Real Product Managers was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Favorite lesson from co-workers: Underpromise and overdeliver.

— -

What did I learn this week?

That I’ve forgotten how to present to the C-suite.

In the most amazingly embarrassing way.

Specific advice to myself:

1. Understand the underlying meeting objective: e.g. Vision alignment over tracking
2. Only the necessary details
3. PM content needs are not the same as C-suite content needs

Also, note to self:

• Finally recraft how you share userflows.

You’ve gone through three presentations where the way you presented userflows was for a design team, not for a business unit. Keep your audience in mind.

The best lessons are learned on-the-job.

⏩ 👫 If you found this helpful, please share it to the people it can help, too.

As I mention in weeknotes I write, I’m a fan of designing in the open.

If you want to follow the things I’m learning along the way, as a researcher, strategist and teacher, follow me on Facebook or subscribe to our yet-to-be-regular newsletter.

Weeknote: Understand your meeting audience (#RookieMove) was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Completing this 30-minute exercise makes teams less anxious and more productive

(This is, I feel, one of the most legitimate and comprehensive-but-concise articles on it. Sharing it here because it outlines the process that one SHOULD do if they were to write one.)

Background

(Or where I talk about how this is all based on an actual experience)

I once had a boss who briefed me about his/her user guide. He/She had a chat with me on my first day of work to lay out the ground rules and “how best to work with him/her” [I love frank, straightforward people. Ask me questions anytime.]. In fact, he/she even asked me to interview some of my teammates about “how best to work with him/her”.

Moral of the story

The boss did not know “how best to work with him/her”.

I actually listened to the “user guide” briefing, because (as My User Guide would say) I believe in people and always give them the benefit of the doubt. So, if you tell me something about yourself — I will believe you: that’s my default.

Now, what my then boss didn’t know was that my teammates’ “boss user guide” was far from his/her version [He/She hates questions he/she isn’t prepared for. Do not ask out of the blue.]. It was actually the exact opposite — even including not to believe his/her version of it.

I won’t say how that all turned out — all I’ll say is that I wanted to prove his/her version of the user guide correct because I believed in the values he/she mentioned in it.

So what?

I’m just afraid that people are going to get on this bandwagon and start writing odes to themselves and what they care about. Which isn’t a bad thing in itself, okay. (Go ahead and write that. Then, clean it up for your resumé).

What is harmful is if you write it ON YOUR OWN expecting that the act of writing it and giving it to teammates automatically makes it easier for them to work with you.

At every point of my career where I learned something groundbreaking about myself and how to work with me — I needed to hear it from someone other than me, and normally after a flub.

Asking for and receiving feedback FROM OTHERS allows you to write a truly useful “user guide”. If you think about it, it makes perfect sense because you need to design the guide for your “users” — which means you need to write from THEIR mental model of YOU. Not your version of you.

Because, unless you’re crystal clear about your strengths and weaknesses, you’ll probably be writing a user manual to a fantasy.

Self-awareness and the “User Guide” wave was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever been asked for a certification for what you do?

Why I’m writing about this

I’m lucky I was only ever asked once. (Although I was once questioned for teaching without a Masters degree).

And, thank goodness that, by the time I was asked — I had already done 3 different forms of research work, led a team, created complex websites and digital strategy… Basically, I had the gall (and the confidence) not to care.

I’m also lucky that the field where I initially worked really doesn’t have a certification for you to practice it — no one certifies Qualitative Researchers. All you have to show for yourself is analytical skill and portfolio.

But, then, I started working in fields where some of the people were certified, and many were not: Digital Marketing, User Experience Design and “Innovation”.

It’s gotten to a point where I’m asked to teach others what I do. Which — apparently — brings up the request for certification over and over again.

This stirs up quite a lot of thought and emotion for me, though. I only feel confidently certified for market research, also self-awareness and facilitation (yes, “self-awareness” is a capability for qualitative analysis; and I have a certificate from multi-week workshops on it). On the other hand, everything I learned about creating digital products I learned from coworkers, mentors, self-studying on the Internet and on the job. In other words, I learned them informally.

[I’ve also worked with certified people. Unfortunately, out of every, say, 6 people I meet who are certified, I only see that 3 of them are significantly more competent than those who aren’t.]

What if I needed to certify people, though?

Let’s go back to the beginning.

Why did certifications need to exist?

Certifications needed to happen to protect industries from non-credible practitioners. Can you imagine going to work in a skyscraper designed by non-credentialed architects and engineers? How would you know whether you’d want to trust the developers of a building, for example?

Would you trust a non-credentialed doctor with your heart transplant?

The earliest “certified” professions had an impact on life-and-death, and practitioner integrity was critical. Newly minted doctors need to recite and swear by the Hippocratic oath.

Fast forward a few years and other professions needed certification as well — accountancy, project management, culinary arts.

Can you imagine if the manufacturing of the Toyota car you were riding wasn’t supervised by a certifiably credible process manager?

Certification as Service; Certification as Product

In this day and age, though, certification is also a corporate employee’s stamp of approval. A badge you wear to tell everyone you legitimately learned something.

You can probably find a certification for every hot career out there.

IT Engineering? Data science? User Experience? Innovation? Machine Learning?

Do these certifications uphold the same rigor that the earlier ones had?

Do you go through at least 4 to 5 years of study and practical application, aside from and prior to passing a national, standardized, regulated test?

What if you did, though?

What if there was a regulatory board exam for the practice of User Experience design and digital product management? What would that test be like?

What would an experience design and product management certification test measure?

Let’s apply what certifications were originally for — and translate them to the field of creating digital products. These parameters should protect your employer and end-customers from potential malpractice, or incompetence. It should say that they’re in your safe, and capable hands.

So, what “harm” can a bad experience designer, product manager or innovator potentially bring?

(The exam and certifying body should test everything that proves that you won’t inflict that harm on people: the responsible and competent practice of experience design* and product management.)

Modern-day Harm

What real types of harm have tech products wrought on people’s lives?

Let’s start with the most intense.

A. Tech products can inadvertently cause or influence death: Case in point, India’s shortage hoaxes eliciting hoarding and stampedes (Whatsapp), the Slender man urban legends (Tumblr).

What could have prevented this? Could something have prevented this?

Potentially, nothing — Potentially, the answer might be that “no one working on the product could have predicted that it would be used” to someday manufacture (mis)information and influence mobs.

What they could have done, though, was set feedback mechanisms, have close community management and data analysis on long-term community impact (“business” intelligence now seems like just one side of the analytics pie). Although, we can’t even be sure of the effectiveness of those solutions.

I therefore elect that digital practitioners working on any social platform need to have extra “expertise” on:

Social impact and ethics.

Creators of digital products need to work out how interactions they design (especially for profit) affect the community they intend to engage in the next year, 3 years, or 5 years.

B. This also leads to more “basic” trait:

Attention-to-detail and Conscientiousness

Let’s say that some of the oversight was just that — oversight. It wasn’t intentional; we are really just usually blind about how our work can sometimes affect others.

[Similar to how the Youtube algorithm let a lot of AI-generated kiddie animated videos (no matter how creepy) get promoted to the tops of related videos section and search results.]

To protect our clients and end-users from accidental “malpractice”, we need to be meticulous about potentially contentious design elements.

In truth, this isn’t necessarily individual responsibility. No one person can think of all possible issues, especially without testing and prototyping.

Diverse teams that openly and sincerely challenge each other are an antidote to being blindsided by unforeseen use cases.

C. Contagious concern for end-users, above all

For responsible UX work, it’s best that part of our test be to assess and successfully encourage or convince teams to move in unison towards something that’s good for users, aside from (or along with) the business.

This also means — communication and clarity of thought may be part of what defines a competent UX person.

On a less extreme case, how about just day-to-day nuances and inefficiency?

You wouldn’t want to pay loads of money for an architect who designs a house that doesn’t work well, right?

So, we have more foundational things — such as:

D. Application of Usability Principles and Methods

One of the basic things a company should look for in someone who designs products that people will use — would be an understanding of how to optimize that product for different types of people to use that easily.

This can range from basic, known principles (such as Fitt’s Law) to testing and iteration.

E. Application of Business Objectives to Design Improvements

This, for me, is foundational — if you’re going to work for a corporation. It’s pretty much why a company would pay for your services in the first place. The best way to prove this is track record though — Do you have the ability to achieve objectives you were hired for?

Of course, the individual skills that this would entail depends on your specialization: interface design, research, content creation, motion design, code, business model iteration.

F. Considerate Assertion (and Critical Thinking)

I need to add this, though — to “counterattack” that last bit. I also don’t feel that a competent product person should just say yes and execute any objective well. You should also be able to humbly, sensibly and kindly express that you believe that the objectives aren’t worth reaching (for good reasons, of course).

Like, if someone made you design a platform for a troll army to efficiently spread misinformation. Maybe, there’s a good reason to say “no”, and an elegant, mature way of saying that.

For now, this is what I’ve thought of. I’ve come up with more attributes than I thought I’d have. This makes sense because any job that needs certification is probably more complex than 4 line-items.

Hopefully, more conversation along these lines builds up towards a more mature practice in our region.

*Here, I will use Cooper’s description of “interaction design” — where one can either be a Generator or a Synthesizer.

Pairaphors: Explaining pair design (metaphorically) | Cooper

**The irony is I just signed up for a class (an expensive one, too). With a certificate of completion. Which I’ll use, of course. (I’ll share why I did this when I finish the course and will be able to give some sort of review about whether it was helpful)

⏩ 👫 If you found this helpful, please share it to the people it can help, too.

As I mention in weeknotes I write, I’m a fan of designing in the open.

If you want to follow the things I’m learning along the way, as a researcher, strategist and teacher, follow me on Facebook or subscribe to our yet-to-be-regular newsletter.

Credible Credentials: What we talk about, when we talk about certifications was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

On learning and re-learning. Self-efficacy.

14 years ago, I was in college.

I was a mediocre, maybe even lazy, student. I spent 4–5 hours a day in my extra-curricular organization. I’d fall asleep in even the classes I loved*.

My thesis-mates and I would start work on our project milestones 2 days before each deadline.

We chose our topic mainly because we were advised to work on something we were passionate about. And the only common thread in our background was some form of sports affinity or involvement.

So, our thesis topic was simply: Self-Efficacy and Sports.

We got a B-, which we were happy with.

14 years ago, I didn’t even know or read up on where the concept of self-efficacy came from. We were just looking for a way to measure whether sports really teaches kids “to have goals and to reach for them”.

12 years ago, I started my first job.

I was scared to try something that was gut-based, so I chose quantitative research analysis.

9 years ago, I was in my second job.

Felt like I would retire there. Loved media research so much; I felt really lucky to make a living off of watching TV and analyzing how people consumed media.

7 years ago, I felt my job wasn’t enough.

I wanted to be part of actually creating and designing solutions, not just analyzing them. I had always wanted to work in advertising, but I could never get in each time I applied. I also felt really uncreative. I couldn’t draw to save my life.

I wanted to work in the design field, but I knew it was beyond my abilities.

Fast forward 7 years later.

I get to teach, lead and do Experience Design work for companies, start-ups and teams. College Me would have never imagined this was possible. Even 25-year-old Me would have never imagined it was possible.

All it took…was a career 180, starting from scratch at 28, and facing my insecurities about my design abilities, but it was worth it.

Now,

I’m working on a service design project where we’re out to try to mould people’s behavior for the better.

I’ve always taught everyone who’d listen to my UX sessions that “User Experience design” is the design of behavior. Until now, though, I’ve only been designing behavior on an interaction level (Can I get the user to click where he needs to click?). Now, I need to deepen my skills because I have to facilitate how people perform habits beyond an interface.

So, I’ve started to read more about behavioral science.

And a name keeps cropping up. Albert Bandura. Each time he’s mentioned, articles say he’s one of the groundbreaking psychologists. His name doesn’t really ring a bell.

Apparently, he’s ground-breaking because he discovered how you can cure phobias in a day — through a process he called “guided mastery**”.

He eventually realized that this had a larger impact on people — and affected how well they perceived they could change, how well they could accomplish things. He was the man who coined “self-efficacy”.

Wouldn’t you know it.

14 years ago, my thesis was about the factors that would lead (or not lead) people to feel they could achieve goals.

Now, after 14 years of not ever reading up on the topic again, it’s my job to understand it more and apply it to my design work.

—

I’m a believer in doing work that you’re naturally interested in. (No, not in the I-wish-I-could-make-money-by-eating-pizza sense, but in the productive, I-actually-enjoy-looking-at-spreadsheets-and-making-recommendations-from-data sense.)

1

What tonight has taught me was that — life is amazing, in that, apparently, interests, knowledge, education can come full circle. Granted that you keep trying to know yourself well enough and you try to stay true to what you want to pursue; despite trends, despite initial compensation (the “What would you do if money was no object?” question).

2

Also, that how you are (in college/ now/ then), is no way a marker of how you will be years later. On some level, yes, we’re still the same people — but, as Alfred Bandura showed — your context, environment, social circle can shape you. You can put yourself in situations where you can overcome former barriers. You can also change your mindset about what you can and can’t do.

3

Lastly, man — sometimes you don’t realize the value of things you learn until waaaaaaay later on in life. Damn.

This is all especially relevant to me these days. As I struggle with a whole direction that I also never imagined — parenthood. It’s testing my “growth mindset”-”elastic brain” beliefs. Every day, there’s so much to learn — what food is good for a 6-month old, what the names of her vaccines are, aside from other life-skills I finally need to learn (hello, Konmari.). Maybe this is just the jolt of inspiration I need.

*Cognitive psych. And Philosophy of morality. Oh, though I never fell asleep in two of my other favorite classes. Hmm.

** Read about his popular experiments from IDEO’s Creative Confidence book, which a friend lent to me last year (Thank you, Ben), and that I didn’t start reading ‘till now.

For further reading, Bandura’s scholarly article:

Self-efficacy defined

Believing you can, then doing it. was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Finally realizing why I’ve always been bothered by that separatist argument.

(To be fair, the Medium post that triggered this was thoughtfully written for a “___ Is Not Enough” piece.)

7 years ago, I was in market research. And, 7 years ago, I realized I wanted to do research specifically on behavior for designing digital products.

My boss said that role was shallow. Fundamental needs are more important, not focusing on the “how”, but the “why”. That research needs to think of the whole person — and I agree.

But, I said, it may be more shallow for you and tactical, but it’s what I want to do and what gets me excited in the morning.

For every “___ is not ____” discussion. I hope those in the “[Profession] is not enough” end, don’t feel pressured to change jobs just because something broader, more encompassing comes along.

Because yes —

• thinking of the whole is more important than a facet.
• Knowing context is always more important than just focusing blindly on a facet.

BUT, it isn’t wrong to be passionate about working on a facet. Like a bread artisan or a sushi master. It means you probably won’t become a chef de cuisine down the road; but, so what — if you sincerely love to explore all the ways sushi can be amazing.

UI is not enough. There’s UX.

UX is not enough; there’s CX.

CX is not enough; there’s service design.

Service Design is not enough; there’s systems thinking.

Copywriting isn’t enough; there’s content strategy.

Content marketing is not enough; there’s content strategy.

Marketing isn’t enough; there’s Product Management.

Project management isn’t enough; there’s Product management.

Whichever you love doing is fine — the important thing is to love it so much you’ll be great in whichever you choose. Don’t feel pressured by society to switch careers just because — BUT it is always, always important to keep learning. AND to consider the bigger picture.

Interior Designers need to consider Architecture, but that doesn’t mean they need to switch jobs just because.

Architects need to consider urban planning, but doesn’t mean they need to be Urban Planners if it’s the field of architecture they love.

Urban Planners need to be considerate of government and public policy but doesn’t mean they should all run for office if they love doing their job.

Suggesting that we should all care about the larger context of our work isn’t the same as suggesting we switch careers just because it’s broader. You can pretty much put any job in “________ is not enough” because, really, no one job is enough.

What’s actually missing in that statement is the goal:

• “_______ is not enough” for what? To what end?

To design an app that a lot of people will use — UI isn’t enough, UX isn’t enough. CX, Marketing, Service design, Mobile development, Content strategy, Product management, Project management — they all aren’t enough. It’s cheesy, but we all just need to work together and respect each other’s contribution to the whole. Work, any work, is a team sport.

⏩ 👫 If you found this helpful, please share it to the people it can help, too.

As I mention in weeknotes I write, I’m a fan of designing in the open.

If you want to follow the things I’m learning along the way, as a researcher, strategist and teacher, follow me on Facebook or subscribe to our yet-to-be-regular newsletter.

“[Creative field] is not [Broader creative field]” and it’s okay. was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

I love frameworks as much as any average research analyst-strategic planner-user experience designer-product manager.

This week, we’re working with teams who are new to user-centered design. We, then, especially feel the need to find good, useful frameworks to communicate ideas in a clean, simple way.

BUT.

Beware. Of the creeping tendency of Templateivitis*.

*It might sound like a similar concept, but this is definitely different from “all-websites-are-starting-to-look-the-same-o-phobia”**.)

Template-ivitis is the increasing reliance on frameworks and models that you can Google, then adapt to explain the current projects and pitches you’re working on.

How is Template-ivitis more menacing than web design patterns? Don’t they use the same logic?

That if you use the visual patterns that users are most familiar with, then they’ll more easily navigate information?

NO. Because…

1. A template is not (automatically) a solution.

Just because you were able to fill up blanks and squares on an “official” framework from a book, does not a business model make — nor a User Experience strategy, or a Customer Journey Map.

Templates are helpful, yes — they allow us to scale our logic, our services and our thinking. But, coming from a template user such as myself, we need to protect ourselves from relying wholly on sophisticated MadLibs to decide things for us. #CriticalThinking #ACarelesslyFilledBriefIsWorseThanNoBriefAtAll.

2. A template is a collaboration tool.

Templates work best in the wild. Like a watering hole in the midst of different species of animals.

They’re supposed to bring people together to discuss, modify and experiment with their ideas.

If you actually read the books Business Model Generation or Value Proposition Design or the Design Kit, you’ll see that they are meant to be used as a means for experimentation and conversation — more than a single-use presentation device.

3. Tools are only as good as the people who use them.

A good template should bring out the best in your thinking.

But, if you’re filling it up without doing the legwork — of reviewing real business performance and analytics, desk research, market research, UX research — then it’s just going to be…a filled-up worksheet, not a “business model”, or a real “value proposition”.

I’m very very thankful that sharing frameworks and mental models are a big part of society and the working world these days.

Thankful that there are brilliant people who were able to distill their thinking into clear models, and decided to share and monetize these.

But, the reality is I’ve also seen the templates underused and abused in client, corporate and academic presentations.

So, a word of warning, if you ever find yourself on the receiving end of a template presentation, don’t be seduced immediately by your presentor’s filled boxes, and do take the time to absorb what they mean.

*On Web Design patterns: Websites are beginning to look the same because of digital products adapting to mobile-responsive design; style guides (such as Material design) and design patterns (which can actually improve usability). The fact that many websites are beginning to look similar is not necessarily or automatically due to a lack of creativity, but more of the increasing need to adapt to usability practices.

Follow me here on Medium, or on Twitter, for more straight-talking, practical stories about how to plan, execute and apply design research.

To stay updated about what my team is reading, Join Priority Studios’ newsletter for a monthly collection of links we found useful for work.

Templates and Frameworks and Models, Oh My! was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. List all of the topics you want to learn about in the interview.
2. Ask why.
3. Double-check your topics.
4. Practice the questions.
5. Iterate.

Some of the more interesting challenges as you grow in a field, is figuring out “How do you teach others to do what you do?”

Especially, when it’s something with no established online tutorial like — “insighting”, or “analysis”.

So, what I tend to do is I break down my process into a practical, scaleable, step-by-step flow.

There has been a lot of buzz around “UX”, and I’m happy that most people are finally getting that the “user” in “user experience” means getting to know your users. Technically, “user experience” “research”.

My own journey to learning research skills was straightforward: I was a market research practitioner. Started in 2005. So, I really needed to go through being educated about research and statistics processes for years — for work.

HOWEVER, with the growing popularity of “UX” and “usability” and “guerilla research”, a lot of people are being made to do research on their own — but can’t afford (in terms of time, or budget) to go through the entire rigor of a full “Conducting Research” course.

Besides, as much as I love the intricacies of conducting research (sampling, questionnaire creation, data processing) — I know it’s a niche job for a reason:

It’s not like everyone gets excited about the thought of talking to at least 15 people a day about their daily habits and preferences for 2 hours, then encoding them and charting them. (Which is why you have A Book Apart’s Just Enough Research.)

In fact, like the whole principle of “minimum viable product”, it’s better to do the research you need, rather than ending up not doing it well or at all because of getting daunted by the full-blown version.

Some of the most common questions for me, recently, have all been about creating an interview flow: Do I ask this first? How can I ask this? What kind of questions do I ask?

Crafting an Interview Flow

The operative word there is flow: Interviews are very engineered conversations, but conversations just the same.

There are existing best practices to how you structure them. And, when you eventually get the hang of it, I actually find it a lot of fun — optimizing how it flows to get the best possible answers (best to mean — “deepest”, most fleshed out answers, okay; not “the answers that I want to hear”.)

1. List all the topics* you want to learn about in the interview.

You heard me, list it all down.

*We’re doing this first because I’ve seen that it’s typically easier for people to think of interview topics first — before they dive into the deeper problems the interview should solve.

If you want to get geeky, there are more formal names for this action. In quantitative research, for example, the output of a survey’s open-ended questions would be called and organized into a “code frame”.

But you don’t need to call it anything, just get them all out on paper.

Excel or a spreadsheet is best, just so you can move them around easily.

Sample:  Say you wanted to conduct a task analysis interview for a Digital Agency, because you wanted to create a product that makes team communication more efficient. 

What topics would you like to ask about?

2. Ask yourself “why”

For every topic you listed down, answer: “Why do you want to ask about that?”.

This helps you get to the Objectives “layer”.

Problem You’re Solving -> Research Objectives -> Research Topics -> Questions

This will help you weed out topics that might be unnecessary for your objective.

3. Go back to your questions. Check if they ask everything you need.

Once you’ve pinpointed the real objectives that you’re trying to answer, go back to your list.

Double-check if each of the questions matches your objectives (because you have to trim your questions as much as possible — the shorter, the better, for your respondents).

On the flip side, double-check if there’s something missing to get to your objectives.

4. Practice on a teammate.

Check if the flow feels right.

This is actually a critical step. Don’t think that this is skippable.

You’ll often discover that how you feel a conversation flows, is different from how it plays out in real life. So, at the very least, try it out with a colleague and see what type of answers you get.

Are there better ways to phrase things?

5. Iterate.

Of course, once you’ve tried out the flow — revise the interview flow if there’s something that needs work.

This is especially necessary for interviews with over 10 questions, but it’ll also help you whittle down whatever interview you’re planning.

Hope this helps in your next guerilla research undertaking. Tell me how it works out.

For further reading

The best practices link from earlier in the post, from Harvard’s Department of Sociology:

Originally published at www.angelaobias.com on August 2, 2015.

⏩ 👫 If you found this helpful, please share it to the people it can help, too.

As I mention in weeknotes I write, I’m a fan of designing in the open.

If you want to follow the things I’m learning along the way, as a researcher, strategist and teacher, follow me on Medium or subscribe to our yet-to-be-regular newsletter.

A Guide for Crafting Interview Guides: Made for non-researchers was originally published in The Redesign on Medium, where people are continuing the conversation by highlighting and responding to this story.