It's Already There...

In recent user research and product feedback I've noticed long-time users of our software suggesting improvements that were already there.

I suspect it's the combination of perhaps three things.
  • The way we asked
  • The user expectations from knowing the software
  • Not wanting to ruin things for others

Ask and You Shall Receive a Response

We've asked, "what would you expect on this screen?" or "would you need this kind of information?"

I'm trying to avoid leading the interviewee, but this kind of question to solicit a response based on the desire to answer. Perhaps the person asked isn't sure or might have a few ideas, but the question itself encourages perhaps a single answer.

Maybe I can leave things more open ended questions and work with our UX researchers on how I can ask better questions.

User Expectations
When asking about some potential functionality, users that know our software will describe their expectations. They'll describe wanting to know the status and relationship of items and their related data. For example, what's published? What's that field name?

If you ask, but don't show them what's already there, they'll likely ask for things they might have ever needed, rather than most of the time. They might also ask for things that are already there but aren't clear or easy to get to.

I'm learning a better approach is to perhaps ask about a specific situation rather than in general. People can easily conjure up the abstracted ideal version of a situation, which can be useful but misses the detail of an actual incident.

Also, it's not the interviewee's fault. As humans, we offload so much information into our context software where they become extensions of our brains. So when asking about something that's not visible at the moment, it's hard to recall everything that's there.

It's Your Fault!

Finally, I suspect that if I asked you if you needed some feature of information in the UI, it's much easier to say it might not be important to you, but maybe someone else might need it.

I'll hear conflicting requests like "we should show this data" from one person and "I don't need that data, but maybe that information could be useful in a tool tip" from another.

And then we realize it's already there.

Final Thoughts

If we listened to every piece of feedback, we'd keep every bit of functionality and UI missing the point of good user experiences. See one of Jared Spool's Kano Model presentations on why this is a bad idea.

Soliciting feedback and hearing requests have their purposes it letting you know what's on your users' minds and what they're trying to solve. But it's important to be aware of how you can influence an answer.

For more on Product Management and User Experience Design, let me plug the This is Product Management podcast. It's definitely worth hearing the different perspectives and episodes are short enough to commutes under an hour.

For information specific to my own projects, see our own UX Community Group and Product Group, where the latest updates (November 2018) feature a video and demo with voice over from your truly. Speaking of which, I owe an update on how we're building the latest UI and what Tridion Sites means for digital transformations.

In a future post I'll likely share some examples user testing and UX research, where there are few questions asked but lots of insights gained.

Oh and congrats to the teams on the SDL Tridion Sites 9 release and updated SDL Tridion DX (suite) group!

Update: our lead UX researcher gave me more feedback and tips for interviews. It's probably good to understand the interviewee's use cases and then introduce the context and thinking behind a given design. It then makes sense to make the questions tangible to the interviewee's specific use cases ("How would this work for you? Would you find this valuable? How often would you use this feature?). However, the interview and feedback sessions are just one user research tool. I'll explore more examples and gotchas in future posts.

Midas Rule

As a new customer, I remember asking my first Tridion trainer the difference between an Embedded Schema and a regular Schema ten years ago.

As a new implementer, I remember creating my first Schema(s) and the reaction of my editorial team when they finally had control over their content library a few months later. No more requests to IT to deploy something to Staging to then re-approve on Live!

They eventually explained to me that, "No, we don't publish to Staging. We just publish to Live and fix anything if there's a problem."

As a new consultant, I remember my colleague asking me how I knew all the "best practices." I had four years of experience with the product by then and a few years "managing" content before that.

As a new Product Manager, I remember telling another colleague four years after that, "well, Tridion doesn't work that way." He reminded me that we could change it.

After a decade in the industry and about 13 years in IT, I'm also realizing I'm not so "new" anymore. :-)

Now as a Product Owner for the DX Suite, I'm remembering last week's demo where dozens of UI improvements were implemented in a sprint for the new Graphene User interface (due after Sites 9.1) as well as a "yass!" reaction from an editor to some small, but significant page editing improvements for Tridion Sites 9.

And today I'm letting the Tridion Docs content model slowly sink into my brain after a great session with our lead technical writer.

By the Midas Rule, many of my colleagues and I were not the first to touch this software, nor will we be the last. But we do care enough to be proper stewards of the previous vision, while we work on forging a new one... in Graphene. ;-)

Passing on the Donut

It's already (only) been 2 years since the move to the Netherlands and I'm saying goodbye as the Donut Product Owner and Hello as a POBA.

After joining SDL Professional Services in 2011, moving from my hometown of San Diego to San Jose and meeting many great Tridionauts from across the pond, my original dream was to learn even more about our other products and our customers at the "Tridion Mothership" for at least 2-3 years. Before that, I wondered if I could do Tridion at least part-time.

However, we already had a great Functional Consultant in Amsterdam while at the same time Product Development had an opening for either a Business Analyst or Product Manager with a chance for to focus on the User Interface.

So I thought of course! Coincidentally, one of the interview questions when I first applied to SDL was what might I be interested in doing beyond consulting. My answer was something like:
"Training or maybe development (well not as a developer, but rather, perhaps, maybe... as part of the development team?)."
Getting the job was like being that Excel geek that gets a job with Microsoft.

That first year was about understanding Dutch home/work culture, learning even more about customers, and even changing work culture through new roles and processes while continuing to share, but from within development.


I also had a chance to work with (in) the Translation Manager team for a bit before kicking off the Second Year with even more product add-ons.

Though we started with the safe and boring Team 1/Team 2 format, by #MidasRule, I dubbed our team, "FT1ntegrations" and also brought Legos to the office, to umm... emphasize the metaphor that we connect modular pieces of software. Yeah.

Proper tea has been replaced by a coffee cup to properly anonymize individuals. No, my colleagues aren't actually Minifigs.

Three Little Pigs

There is a story about agile practices and 3 little pigs. This is not that story.

There were three little pigs who wanted to live somewhere near wolves for some inexplicable reason. Astro Naught the Pig planned to make a design that had a plan for a two-story brick house. A. Gile planned to make a wooden single-story house and would iterate, not increment, on the design to make a great home. Scrappy wanted to face the wolf but only had a straw budget.

Day 1

Astro Naught had designed the ultimate house-designing plan designer and had his first prototyped brick when the Wolf appeared.

The wolf bellowed, "I'm going to..." but Astro threw the brick at the wolf's head and ran to his neighbor. The Wolf scampered away.

Day 2

Astro and A. Gile were having dinner in a single-story wood-framed house when the Wolf appeared at the front door.

The wolf knocked and demanded, "Let me in, let me in, little piggies!" But then he noticed the walls were not quite complete and he was able to slip into the house between some unfinished planks.

The two pigs squealed and ran away into the night in different directions, leaving the Wolf alone, disappointed, and hungry.

Day 3

Hungry and tired from chasing the first two pigs, the Wolf spied the small straw hut of Scrappy Pig.

"Now's my chance!" he thought as he started running to the small house.

As he huffed and puffed from the sprint, he entered the already-open front entrance. It wasn't quite a door, because... straw. Suddenly the straw floor gave out from under him and he fell into a fairly deep trap hole made by Scrappy Pig.

Scrappy Pig continued to solve harder and harder problems until he was renowned and praised for business books like The Way of the Straw and The Night the Wolf Fell.

The Morale of the Story

Iterative designs are good. But not when there is a Wolf at the door. A perfect, expensive architecture is great, but not when you don't have time.

The pig that wins is the one that creatively makes do with what it has, focusing on the biggest problem first. It also helps to be lucky enough that the Wolf didn't appear on the very first day.*

*Successful people work hard. But not all hard work is rewarded by success.

Care to read more? Try sausage.

Thanks to the kids and BSMSO for helping inspire and revise the story of Astro Naught, A. Gile, and Scrappy. Credit to Joel Spolsky for "Architecture Astronauts." I'm not sure if he coined the phrase, but I first learned about it from his blog. I muddle his point on abstractions of abstractions, but couldn't resist the pun.