Month: October 2016

When I was younger, I wanted to be with the in-crowd. The ones who were doing the cool and amazing things, the ones who had friends around them, the ones who looked successful.

I think we all do, on some level. Being human means a search for acceptance, whether it’s acceptance of others or just self-acceptance. We long for validation from outside ourselves, even as we tell ourselves that no, we do not want that, that can’t be what we’re like.

I had a clan of people on the Usenet I talked to. Interesting, fascinating people. But they weren’t all good people. As politics in America turned increasingly toxic, they turned toxic as well. It was hard to be around them and to have a conversation with them, because it all ended up back in the dark underbelly of conspiracy politics.

I was, once upon a time, a churchgoer. The church I went to was young, vibrant, and intellectual. But it was also very, very hard to connect with others. I once threw a birthday party for myself and invited 50 of them. 2 RSVP’d. I felt like a nobody, and it stung. I apparently wasn’t a valuable connection, or I wasn’t valuable to them. When you’re taught that everyone is valuable in a faith community, but the social cliques become exclusionary, you wonder if it’s hypocrisy, or just the way people are.

I left the church. I left that Usenet group. I did keep some people in those circles, but I cut most out. In leaving the church, I really didn’t lose my faith in a deity as much as I lost faith in a faith community being a community. I learned that the only community I could find came from the community I created.

In the years since, I’ve learned the value of surrounding yourself with the right people. People that aren’t “cool.” People that make you uncomfortable, that challenge what you think and what you say. My design peers, my mentors and mentees, are varied, many colors, many sexual and gender identities, many religions, all levels of experience. As a designer, I appreciate having these people to draw from in wisdom. I only hope I can return to them the same value they give me.

A diverse peer group teaches you how to be tighter in your logic while being more sympathetic to the points of view of others you do not understand. It teaches you how to be a better person.

As I’ve gotten older, I’ve learned that I have control over whom I invest my time and energy in. My greatest regret is I didn’t realize this sooner.

You have control over who your friends are. You have control over the level of engagement you want to have with your peers, your neighbors. You should always be respectful, even as you correct them in their faulty thinking. But there is nothing that says you have to invest in these people. And there’s nothing that says they have to invest in you, either. The exchange needs to be mutual, or else you end up getting nothing out of the relationship. And in our interconnected age, we have the ability to seek out those healthy relationships far beyond the immediate geography around you.

Choose your community. Don’t worry about being cool; worry about lifting others up and making them better people. Seek out the healthy relationship and cut out that which is unhealthy.

I’ve tweeted a few times about a project I’m on over the past few months where I produced large volumes of wireframes and documentation.

Well-meaning people are replying to my tweets to let me know that Big Up Front Design means I’m Doing Agile Wrong.

There’s a lot to unpack from that—more than I can fit in a single post.  Today’s post is one in a series of fight-me throwdowns I offer to you, gentle reader.

TRUTH #1 Agile is a software development methodology.

The 12+ software development methods that even Wikipedia groups into “Agile” are all based on the Manifesto for Agile Software Development.

The manifesto itself isn’t a development method either, it’s a list of four values and twelve principles for producing software in a world where (at the time) all software was done using the waterfall model. When it was created, there were no development methods that aligned with it.

The Agile Manifesto was a reaction to a problem where almost all software was developed by a client sitting down with a business systems analyst (BSA) to gather requirements, then the client disappearing into the ether. The rest of development—software architecture, implementation, verification, and then delivery—was done without the client in the room.

By the time the client returned to certify the software, one or both of two things had happened:

• The client’s priorities had shifted and the software they’d designed with the BSA no longer fit their needs exactly
• The whisper-down-the-lane style of development where each group tossed their understanding of the requirements over the wall meant the software didn’t meet the requirements’ intention and the software didn’t fit the client’s needs.

For those of us who lived in those dark ages, trust me, it sucked to spend years building something that, when you delivered it, caused a lot of yelling. It also sucked to design and define something that, when it was delivered, you couldn’t recognize.

The Agile software methodologies, Scrum in particular, tend to embed a Product Owner in with the development team to iteratively provide requirements for the next most important part of the software. Through the Product Owner, the client always has a voice at the table.

The team captures the requirements, builds them, and delivers them for approval by the client, usually in 2-3 week “sprints”, so the client is always on board with the finished-up-to-here product.

If the business climate changes (whether it’s feature set, requirements, or budget), the Product Owner can ensure that the next sprint’s work aligns with the new priorities, so that fewer useless things are delivered.

TRUTH #2: UX is a product design process.

User Experience Design is not a software development practice. It’s a design practice.

The goal of User Experience Design is not to develop products. It’s to design products.

It’s to answer questions like:

• Who are the expected users of this product (and do we have data to back that up)?
• What do the users value in the experience?
• How is the product organized to deliver those values?
• How does the product look and feel to deliver those values?
• How does the user interact with the product to deliver those values?

Regardless of which methodology a development team is planning to use to deliver the product, their job gets easier when the client knows the answer to the questions above before the team starts building.

Not every UX project gets built, or is intended to be built.

Just as an architect can draw up the plans for a building that never gets built, a UX Designer can design a product that’s never built. In fact, roughly half of the projects I’ve worked on never shipped. Some were exercises in exploring new audiences where the business client decided there wasn’t a good fit yet. Some were  situations where we discovered the complexity of the product put its price tag way above what the client wanted to spend. Some looked like fantastic ideas, but the users had zero interest in the products.

TRUTH #3: There are many ways to layer a Design process with a Development process.

UX Design is itself an iterative process. Research, sketch, discuss, adjust, repeat. No Designer nails the design on the first try (and they should be suspicious if they think they did).

Some UX Design is appropriate for layering into an iterative development process — in-sprint, or in-Kanban or whatever your development methodology of choice is.

Some UX Design is more appropriate to do in a big up-front chunk  before the development team is engaged.

In a later post, I’ll differentiate between those two.

In either case, none of the design methods are, by definition, Waterfall or Agile, because those are development methodologies.

CONCLUSION:

If someone tells you that whatever design process you’re using “is not very Agile”, the correct response is “of course not, because this isn’t development.”

Go to the next post on this topic, Doing Agile Wrong: Two Big Up-Front Designs.