ux Blog

5 years ago

Product Owner Retires

Why it is bad to have a single point of failure in a product and what to do about it.

Every day we solve problems. Some people solve many problems, some few. Most likely, there is a person in your project or team who solves most of the problems. Sometimes it’s a Business Analyst, sometimes it’s a Designer, most often it’s a Product Owner. They know the market, the domain, the customers, the competitors, the features. They know how things should work, and they push their solutions hard. Usually, the team can’t resist and just accepts this situation. Is it good? Can we find better ways? Well, we’ll have to have quite a lengthy journey to find out.

Setting the Stage

Imagine, you have a new feature in the backlog. At this point, we have several potential scenarios, each with with a different level of harm:

  1. Leave everything up to the developer.
  2. Discuss the user story just before implementation, come up with a solution and do no specs. Make all decisions on the fly.
  3. Discuss the user story just before implementation, come up with a solution and do the specs.
  4. Assign the user story to a Product Owner, let him come up with a solution and have him do the specs.
  5. Have UX phase, brainstorm a solution and create the specs just in time, before development starts.

You can see that some of the scenarios are good, some are bad, and a few of them are just horrible.

To create a perfect solution, we should answer the three simple questions: When? Who? How? Well, the most important question is Why? We’ll assume it’s already been answered.

When?

Each story has its own life-cycle. It is born, it lives and then dies. There are three important moments in the life of a feature:

  1. Someone has a good idea, and a feature is created in the backlog.
  2. Development starts.
  3. User story is released to production.

When is it a good time to have the complete solution? Obviously, not right after the story is created, as things change, and it may happen that this user story is no longer required. It may just be deleted from the backlog in the future. Somewhere in the middle when we have more data? Maybe, but still not perfect. The perfect match is when we have the solution right before development is about to start.

Feature Life Cycle

In this case, the solution is fresh and shiny. Everyone in charge does remember why things should work exactly the way described in the specs. It is certain that the user story will actually be implemented, so the solution and the time spent on it will not be thrown away.

If a feature looks very simple, the UX phase can start about one week before the implementation. If a feature is complex, several months may be a good time frame.

Who?

Many teams rely on the Product Owner, Business Analyst, etc., and expect solutions and specs from them. A team doesn’t care about the solution, but does care about the completeness of the specification. Sometimes this works — but in most cases, it doesn't.

Some teams rely on communication and do not create specs at all. They brainstorm a solution on the fly and then jump to coding. Sometimes this works— but in most cases... well, you get it.

Some clever teams rely on a group of people that consists of developers, testers, designers, and product owners who brainstorm the solution, find the best one, then iterate and delegate writing specs to the product owner. And these teams rock.

Why are the first two cases bad?

The Hero

Yes, Product Owner is responsible for the product. Yes, he knows a lot. Yes, he can solve problems. And, yes, you expect too much of him. It is quite unusual to expect the best solution from a single person. It is always better to have a small group of people with various skills, various backgrounds, and various focuses to find a great solution.

The Product Owner can brainstorm everything alone and write all the specifications. He can haul the product alone. As a result, he would be a single point of failure... while there are many other buses in the streets.

Run, Lola Run!

The communication would be one-way, without much collaboration. In such an environment, the Product Owner would tend to ignore the opinions of other team members, since they do not participate in problem solving. If you don’t participate, why the freaking hell should I care about your opinion?

Knowledge sharing would be zero. The Product Owner is a domain expert, he knows a lot. But the team gets zilch from his experience. There are no discussions, no collaboration, no two-way communication flows.

I used to be such a person. It was not good for the company.

Product Owner’s Rule #1: Don’t do everything alone

The Rush

Got a real problem? Get together, brainstorm it quickly, get shit done, and kick it out of the door. Sounds good? Hell, no. The good thing is that you don’t waste time and rush straight ahead. The bad thing is that the solution would be great rarely, good sometimes, and in most cases just average.

In "the rush" mode you tend to cut corners, take the first acceptable solution, and go for it. There are situations when this is good. In an emergency case, this is a viable strategy — but in the long run, it will not work. Rush mode is very dangerous. You might even be proud of it and call it “Agile”, but it is not.

— OK, the quick add feature. Who’s got any ideas?
— Well, let’s just put up the Add Task link . You click it and see the input field with the Name label and Save button. You add one task and see the input field again, so you can add many tasks quickly.
— Great! Let’s do that right away.

Maybe this is somewhat stretched, but in reality I saw very similar situations (and did very similar things myself!).

Product Owner’s Rule #2: No rush

The Team

I bet you expect a viable solution now. Here is the algorithm:

  1. Brainstorm every feature in a small group of 4-7 people. Invite developers, invite testers, invite designers, invite product specialists. Invite everyone who has diverse skills and can contribute to a discussion.
  2. Think. Talk. Draw sketches. Learn some techniques like Design Studio. Actually use them. Draw sketches.
  3. Build trust. Support honesty. Ban sarcasm. People should trust one another, or you will have a bunch of gamblers instead of a team. Don’t be afraid to criticize bad ideas. The people who can’t stand some reasonable criticism should leave.
  4. Repeat. Several times for each feature. Mix people. Invite new people.
  5. Eventually, several teams will emerge: the teams that can solve problems without you.
  6. Find people that can lead features and be responsible for the solutions. Let them lead UX sessions and play the Feature Owner role.
  7. Create beautiful specifications (this is where I really suck).

It took me 7 years to come up with this solution. It works.

UX Phase

Product Owner’s Rule #3: Spread the knowledge, use diversity, delegate

How?

The “how” question is very broad. How to form teams? How to find solutions? How to evaluate them? How to document solutions? I’m going to just scratch the surface here.

Creative processes are hard to structure and hard to estimate. In general you don’t know when you’ll have a great solution. It may take several days or several years.

Each Feature Team has its own UX phase. Some people like to think alone, have decent preparations and then share ideas. Some people like to brainstorm things ad-hoc. Some like to sketch a lot. Some like to create paper prototypes. In general, it does not matter which practices and tools people use. The must-have rules are:

  1. Diversity. Team should consist of diverse people.
  2. Iterations. First solution is not always the best. Neither the second, nor third.
  3. Feedback. Team should share potential solutions with other people and with customers if possible (and listen to their feedback).

UX Phase Rules

There are many practices and tools you can try. I’ll just list some of them here:

  • Design Studio. In a nutshell, you have a group of people. These people can split into teams or work alone. They have limited time to sketch the solution and then present the solution to everyone. Solutions are criticized. Then, they iterate based on the feedback and sketch again. We’ve been using this approach with good results. Yes, it is time consuming. However, time is not important when you want to spread knowledge. So use Design Studio in the early stages of people's involvement in the solution phase.
  • Sketches. The ultimate tool to brainstorm, explain, evaluate, and present ideas. The main advice I can give is: hide your “OMG I can’t draw!” fear and sketch a lot. You will get better eventually. Sketch + speech is so powerful, so fast, and so cool. You can iterate very quickly, try a dozen approaches, and skip bad solutions.
  • Critique. Do it. Express your opinion openly and politely. Don’t hesitate to upset someone. You solve problems here. Bad solutions should be thrown away. If you’re afraid to say something critical about your boss’s solution — it’s a bad sign. Fuck the common brainstorming rule about ideas and critique separation. This is only needed if you don’t trust each other. Trust gives you freedom of speech. Use it appropriately.
  • Diversity. It really works. There are many proofs and observations on how diverse teams outperform experts and solid “think-alike” teams. Try it.
  • Paper prototypes. Not as fast as sketches, but still good. With paper prototypes you can evaluate flows and find bottlenecks. It’s easy to grab them and ask some teammates to try something. You can even shoot a video and share it with people.
  • Dynamic Prototypes. HTML+Javascript works best for such prototypes in most cases IMHO. However, there are many other tools that do provide decent solutions. We’ve had a somewhat mixed experience with live prototypes. In some cases they did work, and we got valuable feedback. In most cases, we spent too much time on them, and feedback was not so useful. Prototypes work great to prove some limited ideas about a solution, but they don’t work as full-blown usability tests.
  • Usability Tests. We do them on a real application now. About 10 tests give a ton of feedback.

Product Owner’s Rule #4: Learn and try new things

The output of the UX phase is quite simple: feature specification. How to create beautiful specifications? We’ll talk about that in the next article with an intriguing title “Visual Specifications”.

5 years ago

Do You Speak Human, Software?

A while ago we shared some thoughts about software apps as the living systems. This concept opens up a huge space for insights in human-friendly software design.

As software apps evolve over time, they are getting closer and closer to people. The challenge here is diversity of people's minds. The diversity of contexts in which people live and act. Given the diversity of mental extensions, something more important is always in common. It's about emotions. Emotions can do a lot more than logical reasoning. Remember Apple fans, buying more of Apple products out of "I just like it". Emotions are responsible for these just-like-its, when there's no rational need to cut a $XXX, or even a $XXXX,  hole in someone's bank account.

We feel very good when a software app tells us, "thanks for taking your time to tell us what you think" (that's what Skype does). We feel good when a software app cares for us by saving our time with clear instructions, what-to-do's and error messages. Lame language can be a source of bad mood, it throws people out of their flow, instead of helping. Visuals and words create this interactive landscape together.

Here's the list of basic human emotional needs:

accepted
acknowledged
admired
appreciated
approved of
believed in
capable
cared about
challenged
clear (not confused)
competent
confident
forgiven
forgiving
free
fulfilled
heard
helped
helpful
important
in control
included
listened to
loved
needed
noticed
powerful
private
productive / useful
reassured
recognized
respected
safe / secure
supported
treated fairly
trusted
understanding
understood
valued
worthy

As I tried to map them to digital experiences, it turned out that software could cater for about 60% of them (what's your take?).

Let's see how software does this job.

Mint

Mint is a personal finance tool. They pay much attention to the feelings of safety and security.

"Remember kids, safety first" is a strong emotional caller. The lock with the mint leaf is smoother, but still emotional. The part on bank-level security appeals to logical reasoning.

Next one:

The ban sign says it all. There's no real $$ here, rest assured, no one will touch your money, including you.

You're cared about when you see this:

The concept of mint (mint leaf) is very smart. Which association do we usually have with mint? It's something comforting, soothing, something that makes us free from worries and anxiety. That's a great emotional token for a personal finance app.

Trello

What I liked right away about Trello, the collaboration tool, is the Husky dog icon. Well, maybe it's not exactly Husky, but I like those dogs, and for some reason I thought it's a Husky:

What I liked even more is the message of serving humans. The 500.000 number looks reassuring to a new user.

Trello means business, and cares for your time. You don't linger even an extra second on their sign-up page:

Speaking of sign-up and login pages, bad captures totally kill good emotions. They make you reload and reload the capture image, and still wouldn't let you login. You can live with a login capture, as an app usually remembers you. But anyone who has a capture on their sign-up page is committing a slow suicide:

Back to Trello and to their sign-up process. When I see this:

I have a mixed feeling of approval, empathy and regret. Here's why. I can see that these guys are trying to know my real name, that's why they have put up a message about the full name length. But I know too well (as we have a sign-up form on our web-site) that if someone wouldn't want to give their name, they wouldn't give it, and this note would be of no use.

Their account activation message:

I feel reassured and in control.

As Trello welcomes me, I can see that they have taken one step further in serving humans. They want to guide based on how people evaluate their previous experience with collab tools:

Evernote

The most emotionally insecure app that I've tried lately is Evernote. They have a good message on their web-site, but what you see inside the app and during the sign-up is confusing.

First, the elephant logo:

I don't understand what an elephant has to do with my notes and images put to one place. Maybe it is supposed to be a symbol of everlasting wisdom. But there's no emotional appeal for the app from my side. Elephants are nice, but they don't fit in here.

Evernote's sign-up is severe like a Quaker. Here's their unhelpful "user name not available" message:

It says nothing to me, accept that the name is not available. No hint on which available mods I can try. I had to mess a bit with figures and underscores, until I got this:

Evernote uses machine language. There's no feeling that you're welcome here.  Sometimes it's the opposite, sign-up forms can be too off-hand. I don't want to be tapped on the shoulder like that guy, for any single line:

Back to Evernote: it had even more confusion in store as I tried to make the first note. Here's the screenshot:

The Set URL context action. Which URL? For what? I typed something in there, but when I tried to access the note later - no success.  Then Done and Auto Save on top. Hmm. Why Auto Save when there's Done there? Which goes first? Should I rely on Auto Save, or should I click Done? Maybe Done is supposed to work when Auto Save is off? Then why keep it there when Auto Save is on? Questions like these rushed through my head, and the app did not offer any answers.

The "Set the note's location" screen was a bummer. Am I supposed to know the latitude and longitude of my whereabouts in every new location? Maybe they have the auto define location feature somewhere (I can't imagine that they don't), but I was not offered this option, and guessing the latitude/longitude is too challenging a task for simply taking a note.

I don't think I will be using Evernote. It's too confusing and insecure. Well, they must have more options than taking just notes, as they position themselves as "capture anything- remember everything", and maybe the other features in Evernote work great, but I don't care now, as my first emotions about this app were negative.

Ebay

Now let me show you my favourite. What if I forgot password? This piece from Ebay is a beauty:

Sensible display of case sensitivity. I like words and everything about playing on words, so it's like a candy to me.

We have so many exciting options to make software speak human language. We can do it with visuals and words, as long as we keep this thin line balance, where software approaches people gently. Like a professional English butler.

Related articles:

Why People Don't Understand How to Use Your Software?

Help People Understand How to Use Your Software

The Paradigm of Project Management Tools

6 years ago

The Future of Agile Software Development

Software penetrates every pore of human existence. We look up the weather info over the web, giving up on outdoor thermometers. We’re driving to destinations with GPS navigator (forget paper maps with their G7 sections on page 59). We turn on RunKeeper when riding a bike to calculate the average speed and run and boast in Twitter. We’re using software every single day of our lives. It seems we’re hugging our dear gadgets a lot more than our loved ones.

No one knows the exact how-to of writing great software fast, that’s the problem. Waterfall passed away at the crossing of 2 centuries, whereas new software development methodologies (agile) fail at solving the fundamental problems so far. We’re living in very interesting times. Software development industry grows fast right here, right now, and the foundation for a quantitative leap is building up.

——— Read the full article ———
6 years ago

Inner List Design in new Views

We are designing Views in TargetProcess and this is how Inner Lists look like.

We took the first concept from our last post — https://groups.google.com/forum/#!topic/uxtargetprocess/zCiquWLM_N0

I would like to highlight a couple of things.

Quick Add of Tasks and Bugs

Now you can quickly add a bug or task to the User Story without leaving a page.

Drag and drop to prioritize or change state

 You can easily change the priority or state of bugs and tasks using drag and drop.

Inline Edit

Change name or effort on the fly!


 

 

People assignments

Assign, reassign and find people quickly.

Effort Control

Time spent/remain indicator shows a relative size of tasks and bugs. You can clearly see what task is the largest and how much time is spent and remains.

All actions

You can use action popup to add time or convert a bug/task.

Collapsing Block

You can hide a large block to access relevant content quickly.

ID Indicator

In the inner list we combined entity-type indicator with the entity ID to use space better. 

We’ve already started the implementation and are going to release it in a month.

Try for free

Account url: *.tpondemand.com
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy