#ixdn00b

[designaday]

Aligning Stakeholders

During a World Usability Day panel discussion, I was asked, “How do you align stakeholders with differing priorities and goals on a UX project to ensure a common vision and direction?”

One of a designer's superpowers is their ability to visualize concepts. There's no better way to align stakeholders than to make it visual. This gives everyone a common reference that they can understand and provide input to. Making it visual also makes it memorable.

This may take the form of a flowchart of a business process, or it may be a day in the life of a user depicted through a storyboard. Such artifacts make it easy to communicate to everyone—team members, customers, and users—and facilitate questions. The invite participation in the story, and that helps build a shared sense of ownership.

There's no better way to get everyone on the same page.

[designaday]

Redlines

A junior designer once asked me, “What should I include in a redline?” A “redline” is a UI specification document, named as such because it was common to use red lines to mark spacing, dimensions, and other callouts. A lot less is required today due to more capable tools that make it easier to transfer the work that designers do into the code that developers write. Many designers don’t bother creating much in the way of specifications at all, but believe that to be short-sighted. There is still value in documenting intended behavior. This is what I redline in UI specs.

Initial State – In what state is a UI component first displayed on screen (e.g., enabled, disabled, hidden)?

Initial Value – What value does a UI component, like a form field, contain when first displayed?

Hint Text – Some fields display hint text until you type content into them.

Events – What happens when you, or anything, interacts with a UI component? Very often, a single component will have multiple events. (e.g., on load, on change, on hover, on press).

Content – Many UI components, like menus, display content.

Format – Form fields sometimes display content in a specific format (e.g., date field).

Required – Which fields must a user fill in to proceed?

Validation – The system must check certain user input to insure it is valid (e.g., a unique name).

Permission – Some UI components will only be accessible if a user has a specific permission.

This isn’t an exhaustive list, but it covers the most common information.

[designaday]

Once the “coding phase” starts

A junior designer asked me, “How do you work with developers once the coding phase starts?” Well, I wrote an entire book about that. But I want to point out a flaw in the question: you don’t just start working with a developer once the “coding phase” starts. You work with the developer from the get go. As soon as there’s a problem to be solved or an opportunity to be realized, you should be working with the developer. You should be working with the developer right out of the gate to make sure you have a shared understanding of the problem, its context, the requirements, and the constraints. Because if you’re making a bunch of decisions without the developer involved, you’re in for a world of hurt when you hit that “coding phase”.

But let’s get another thing straight. Whether you’re Lean, or Agile, or some other hip methodology, there isn’t really a “coding phase” any more than there is an “empathy phase” or a “testing phase”. These should all be happening in concert.

You should be working with the developer all the time. Even when you’re not working. You’re on the same team. You have the same ultimate goal.

As for the how, read this.

[designaday]

PM vs PO

When I was called in to consult a young design team, they asked me what I thought the difference was between a Project Manager and a Product Owner. This was before I was aware of SAFe, so I didn’t understand the question. I was puzzled as to why an organization would have both roles. They didn’t understand it either.

This is going to vary from company to company, and even between divisions within a company. Some teams may only have a PM, while others have only POs. And the teams that have both may have responsibilities assigned differently.

Generally speaking, however, a PM is the one person that is shepherding the vision for one or more products. They spend their time working with sales, marketing, customer support, and management to ensure that all groups are aligned to that vision and that the vision aligns with the market. They’re concerned with budgets, schedules, features, customer needs, and the competition.

A PO, on the other hand, is typically focused on a single product or capability area, and their time is spent with their scrum team. They groom the backlog, prioritize work, write stories, and represent the PM’s interests. They also have the responsibility of being the primary liaison between the team and all other stakeholders, including customers and users.

Understanding the nature of these roles, it’s no wonder that UX is a fertile source of both POs and PMs.

[designaday]

Innovation Pipeline

I was provided with a list of questions prior to meeting with a junior design team I was consulting. One of the questions on the list was “Does your team develop solutions that can be added to an innovation pipeline? Or are you merely told what to do?”

It’s an odd question. We didn’t get to this one during the discussion. If we had, before answering, I would have asked a number of questions of my own to determine the context this question was resulting from.

What exactly is an innovation pipeline? I’m imagining an Agile backlog made up of ideas the team has had that no customer has volunteered to pay for. In this hypothetical situation, the team would be given time to research, prototype, and test these ideas for potential inclusion in a product.

Let’s go with that. The next question, then, is “Where did the ideas in this pipeline come from?” Are these singing-in-the-shower, apple-on-the-head ideas, or were they prompted by things users said or observations made about the way users work?

Perhaps more important than the source of inspiration, is there any kind of business case for them? Has a cost benefit analysis been done? Has anyone asked a user if they would find the concepts useful?

And finally, how do these “solutions” differ from the other work you’re doing? Who’s telling you what to do? What is the authority of their direction? I’m not talking about organizational authority—I mean knowledgeable authority. Are your instructions based on information about your users, their work, and how they use your product? Is part of that direction to carry out research, design, prototype, and test solutions? If not, you’re dealing with an organizational issue.

On the other hand, if this question was birthed from some level of boredom with solving mundane usability issues in your product, I would advise you to reflect a bit on what your role is and why you took the job. Think about the way you approach your work and the heart you have for your users. It’s not about you.

To answer the question, I’ll say this: My team develops solutions to problems that are proven to be worth solving. We are free to propose changes to our products, and those change requests will be logged and considered. To be prioritized for work, there must be a demonstrable ROI. That means that a request made by a customer that is paying for our software is likely to take precedence over a pet idea I had while driving to work. But, if I can show that my pet idea is going to save our customers hundreds of thousands of dollars, well, open that valve and get the innovation pipeline flowing.

[designaday]

Proxy Roles

A junior designer posed the question, “Does your team include proxy roles, so others have authority while the primary is not available?”

As I’ve explained before, my team is very small. We generally stay informed about what each other is working on. That way, when one of us leaves on vacation, another can pick up the ball and keep it moving towards the goal. If one of us isn’t immediately available, and a decision needs to be made, we trust each other to be able to do that in our stead.

I intend to scale this practice as my team grows. Not every designer will know enough about every other designer’s work to be able to step in at a moment’s notice, but there should be more than one person informed about a given project. It’s never a good idea to have a single point of failure. Disperse knowledge to mitigate the risk of the proverbial bus.

[designaday]

Stopping

A junior designer asked, “How many iterations before we say, ‘no more’ to meet the deadline?

It’s not the number of iterations that matters so much as the quality of the solution. Certainly, there needs to be some amount of iteration. Even if you end up implementing the first concept that came to mind, without trying other ideas, you can’t be confident that you have the best solution. And while a good team could iterate on a design for months, there will be diminishing returns. Just because you have more time doesn’t mean you should use it. It may be more valuable to move on to the next challenge.

The real question, then, is, “How do you know when it’s done?” You should already have some goals for your design. Some of those goals will be functional requirements. Some of the goals will be standards and conventions your team follows. Some of the goals may be considered “minimally viable” while others are for version 2 or “nice to have”.

Does the design meet the goals you have for the build that stipulates your deadline? If so, you’ve probably iterated enough. If not, well, back to the drawing board.

[designaday]

Team Makeup

A junior designer asked, “What are the different roles and skillsets in your group?”

I manage a very small UX team of three with two defined roles. There are two interaction designers and one requirements analyst. Both of the designers are generalists, as am I. Together, we cover all of the following skillsets:

visual design (graphics, icons, data visualization, etc.)

media production (photography, video, audio, animation, etc.)

information design

UI design

research

sketching (pencil, wireframes, mockups, etc.)

prototyping

usability testing

functional testing (writing and running test cases)

front end implementation (HTML, CSS, Sass, JS, Angular, etc.)

documentation

presentation

facilitation

writing

Not everyone has all of these skills, and we are each stronger in some skills and weaker in others. Together, we make a very capable team able to punch above our weight class. We’re extremely flexible.