Agile

The Delight is in the Details

Published on March 19, 2014

Some time ago, I was sitting in a client meeting, reviewing the QA version of their website’s check out flow. The development team had just finished putting together all of the changes that I had designed for checkout, and I was looking through to make sure everything matched up. Luckily, many of the items that I had designed were accounted for, and the QA site was looking great. On the flip side, I found a few, smaller items, that had been missed. When I asked the technology lead about them, he replied that we didn’t have time to go back and fix them, and since they weren’t core functionality, we could put them on the backlog for later. This got me thinking ‘How many times have I heard this before?’, and then I thought ‘I know these items would enhance this flow a thousand times over, but I know that they’ll never really get done. We never actually go into the backlog’. Then I got to thinking… why?

question mark

Why is it that we forget about the little things? More importantly, why are the details of our designs and ideas being overlooked and missed? I have been in this profession for over 10 years now. This is a trend I saw when I first started, and I still see it today. Those building out our designs, often don’t see every detail, and when we point the smaller details out, they are often not important enough to fix. I don’t know how our current state still includes a lack of getting into this detail.

And not developing and designing to the details causes us some problems. First off, the details are usually where the “delight” of a product is. Follow a site like Little Big Details and you can see all of the many small details that make products so much better to use than their competitors.

The second problem we see when we over look details is that these small details do not usually take a lot of design or development time to make happen. In fact, if we took the small amount of extra time to design and develop the details, we’d see a tremendous payout with the user’s experience with our product. Thus we are forgoing this return of user delight, in order to make a schedule, or stick to a development process.

The third problem is our product experiences are not progressing at a rate that they should. I believe that missing these details is what is stifling experiences across the web. It’s not just the big product ideas that set a website apart. Most times it’s simply the UI and flow around that website that makes the difference. But without the details, and holding others accountable for designing and coding them, we are missing out on our own progression.

The thing here is that I don’t know why this is still happening. Why do we allow designers and/or developers to miss the details? Obviously there is more than just the UX team in play, and it’s a technology community problem, but I’m just not able to see why I’m having the same conversations from 10 years ago still today.

Ten years later text

Therefore, I write this piece as a question to all of you. How are we still here, and how do we solve the problem of detailing out delight, and still not seeing our details being designed to and developed for? What am I missing that you are seeing out there in the world that can help me, and all of us get there?

Ultimately my goal is to stop getting these small “enhancements” put on the backlog or “shelf” and to start having my teams get it right the first time. I believe by doing so the products we all work on will be much better off, and our work can progress exponentially because we won’t keep coming back to the same old conversations.

Thus, what are your thoughts on how we can move forward from where we are to getting our details designed and developed correctly the first (or even second) time around?

Maybe Agile REALLY Isn’t for Everyone

Published on August 12, 2013

Part of the 5 Minutes a Day blog series

Intern Kofi passed along this link to me saying that it would be a great topic for a post for the site. Normally, I’d love to write a long piece on something like this in order to really dig into my thoughts BUT, time will not allow it. Instead we’re going to review this piece in five minutes (or less).

The main takeaway is that Uber, a traditionally agile shop, stopped its process for the sake of its marketing and future product. They realized that Agile is great for software development, not so great for marketing (something I’ve touched on before), and therefore stopped their engines (pun intended) and did something unheard of. They actually went back to waterfall to rethink their site.

Wow! Finally someone is publicizing this. I’ve been saying for a long time that process for process sake (i.e. using Agile just because it’s a new trend, saves time, etc) is no good, but that is just what many of our companies are doing. Unfortunately for us UXers and designers, we are the ones that usually feel the most pain for this effort.

But, imagine a place where someone says, “hey maybe this process just won’t work. Maybe we should try something else?”.

I don’t hate Agile. I just hate the misuse of it. I hate that we don’t think about the places and times to use it, and instead try to force the square peg into the freakin round hole. I hate that we don’t think before we do, but most of all I hate that we can’t talk about it freely, without getting kick back from the Agile champions (well at least most of them). What do you think?

Pssst I’m looking for Guest Bloggers. Could this be you?

Learning UX in a Lean Environment Part 2: The Journey Not the Destination

Published on July 9, 2013

Guest post by: Kofi Aidoo, Intern

Author Greg Anderson said “Focus on the journey, not the destination. Joy is found not in finishing an activity but in doing it.”

As I sit back in my Brooklyn abode and reflect on my last 3 months at The Starter League (TSL), an independent “school” that teaches entrepreneurs and enthusiasts the technical skills to venture forth with their own ideas or for some like me make a change in their career, it’s this quote that comes to mind.

In my last post I was adapting to Learning UX in a lean environment. Today I will wrap up my experiences and learnings in my final 6-7 weeks as I tried to maximize my learning while building my own application.

Here’s what I learned:

#1 – Always make time for others! This is the most important thing that I learned. While battling it out over the last few weeks I hit a few roadblocks both as an individual and also within the confines of the team. Help always came from one of 2 colleagues in the web development class and UX classes. One of them was basically at TSL to build his business back in his native country and had little time for deviation, the other was still working remotely and had other deadlines besides his 3x a week class. Both were technically advanced and really understood backend development as well as front end design. They would spend the time to review concepts or explain html and it was humbling. So take the time to help. You will benefit from the learning and camaraderie that develops.

#2 – User Stories are key. User stories are quick ways to put features into sentence form. Each sentence places the feature in context with the user. At TSL there were a few conversations where developers were dismissive of the need for UX in the development of an idea. Many didn’t see the need. Yet they were still dependent on a UX tool in order to develop their ideas. Developers were taught the value of user stories and the development of good user stories in order to know what to build both for a Minimal Viable Product, as well as, for the whole system. It was refreshing to hear the developers I was working with demand User stories and want to work through the research and process to refine them even more. Demonstrating the value of UX to developers in such a simple term as the User Story is a good way to bridge the gap between front end backend.

#3 – Understand all your technical limitations from the beginning. When I decided to build my application I was fortunate enough to find 2 very competent developers who wanted to be part of the process. They understood the value of UX, and, as I said in the paragraph above, were even involved in the process of defining the MVP and user stories from the beginning. Yet all was not smooth sailing. Having defined the MVP and even going through a wireframing session with them on whiteboard, my other UX/HTML teammate and I began to build the frontend from scratch using our own html and css that we had defined. Yet when it came time to integrate front end with backend (or so we thought) actually doing so was not as simple. Our ground up html didn’t mesh with their template based system and it would take too long to integrate. So in the end we had to rebuild our html to make it easier for the devs to integrate the product which,with the time left, meant we didn’t “finish” the MVP by the end of the program. Still 3 of 4 of us are committed to continuing on the project and it feels like an exciting beginning.

Finally, the biggest lesson I learned from the whole program is that UX is NOT, I repeat, NOT a lean process. It takes time. Everyone wants to move fast and iterate quickly, but we still need to reference good solid research. The best ideas address a witnessed or experienced user need. A properly researched and wisely applied strategy will uncover the breadth of your user needs. It will also reveal other exploitable areas. This requires time spent with the users and the data to produce the right insights. The UX process can be used to inject momentum into a multi-stage agile development process and when done so can be very beneficial. But an agile UX process seems to be self defeating and limits the strength and power of the output from UX work. Can the UX process be aligned with a good research strategy to support a lean and agile development? I would say yes. But, can an agile process replace a good research strategy, I would say no.

Like all journeys my time at TSL was not as straightforward as I would have liked but in the end I will say the experience was definitely more than worthwhile and I would recommend the Starter League to anyone who wants to dedicate the time to learn in a welcoming, active environment. I’ve been given the feeling that I know and understand UX much better, but I still have a lot more learning to do. Thankfully I now have the confidence to go learn anything whether it be HTML and CSS, visual design or even J-Query. And that has, more than anything, been the greatest value of this experience.

The Secret Step of Agile

Published on February 2, 2011

Agile / Lean development is all the rage these days… and for good reason. It is a great way to come up with and release solutions much more quickly than how we’ve been working for years. And the best part for UX designers is that no solution is ever “final”… iteration and change is a key component to the methodology which allows us to receive feedback on our designs and continually update them to be better. Seems like a perfect world right? The problem with Agile, for most UX people, and for companies, in general, is that they are not aware that there is a step, a very important one, that comes before they can even jump into the Agile mix of things. That step being creating and agreeing on a product / UX strategy for what needs to be designed and developed in the first place… or as I like to call it, discovery and scoping.

Not being aware of the need for a agreed upon strategy can cause several issues. The most common one that I have seen is that people jump into Agile expecting it to solve all of their problems. We’ll just take some ideas, write them up as user stories, throw them into the “hopper” and Whammo!… Agile will get them out the door quicker than before. Often though, this method fails. Either the UX team is unable to design “quick enough” because they are not given concrete, research based ideas to design to and iterate on, thus “slowing down” the entire development process. Or the development team is unable to release due to bugs and/or incomplete use cases, thereby not having even a beta product to release “quick enough”. There are tons of ways that this method can fail, but the problem occurs when people blame agile for the failure, and not their lack of planning and decision making.

Taking the time to come up with a strategy for what will be build is a very important, if not the most important, step for successful development of any kind especially in Agile. By interviewing and observing user behavior as well as analyzing the feedback on a current product or new product idea, and taking that information to infer future user needs and behaviors, we can create product road maps that map to our users’ goals and tasks. UX should be a part of this step, and should help lead people through the discovery phase, as it is our job to keep our eyes on the prize, which is, of course, the experience of the user has with our product or service.

Creating a product road map (or experience road map if that terminology is more comfortable for you) allows us, as a team (UX, business and tech alike), to sit back and prioritize based on business need, user need, and technological complexity, thereby bubbling to the top the most important features, and exposing the rankings of the remaining features. After prioritizing, we now have a list of what should be designed and developed, and when those features should be developed, which we then use in our agile development iterations to keep things moving as smoothly as possible (this is software development, we know it’ll never truly be smooth :-)). Also, by keeping in mind that your strategy will iterate and change based on changes in the competitive market, user feedback, technical updates and innovations, one should anticipate constantly updating the strategy, in order to amend to these changes.

Thus, strategy (and prioritizing and scoping that strategy) has a big place in the agile world. Creating and adhering to it, as well as updating and changing it allows us to have a successful agile design and development environment. By taking the really big, goal changing decisions out of the execution step, aka the agile environment, and putting them in a different environment (although closely related and perhaps having the same groups of people) we allow agile to do what it is intended to do, design and develop the features that the user needs in a quick, efficient way. Agile was never intended to solve all the problems of the design and development world, rather it was intended to make the execution phase of this world more efficient, and pulling the strategy & scoping decisions out of this phase and defining them prior to the start of this phase, help to clear up the confusion.

So, before you decide that agile is the way that you are going to go, take some time to think about what you are really trying to put out to your users, but also to determine what problem you are trying to solve by implementing a new design & development methodology. Discovery, as well as scoping and prioritizing based on discovery, is, in my opinion, the most important phase because that is where we will find out what problem we are trying to solve for our users. Then we have a clear vision of the goal of our design and development, and we can execute that vision with a clear mind. Agile will not solve all of the problems of the world, however by planning, and doing the proper upfront analysis, agile can help release the solutions quicker, can save money for, and can bring pleasant and enjoyable experiences to the people that matter the most… our users.

Follow Up: Issues with Agile, UX and How We Talk About It

Published on October 25, 2010

This week Johnny Holland Magazine published an awesome article by TheLadders.com Director of UX Jeff Gothelf. In it, Jeff talked about how TheLadders implemented an Agile methodology in their company. It’s a great read, so make sure to check it out: Beyond Staggered Sprints: How TheLadders.com Integrated UX into Agile.

There are several things that I want to point out about the article as well as how TheLadders integrated UX with Agile. First, the article points out that they failed. In fact, they failed several times before they were able to gain momentum and create a functioning system. They admited to their failure, but they didn’t let it deter them. Instead they learned from it and tried again.

Second, and more important, is that Jeff actually describes in detail not only the steps and attempted processes the team took, but also the tools that they used along the way. He also describes when and how they used these tools as well as what worked and what didn’t. This is exactly the type of read I was hoping to see more of when I wrote Issues with Agile, UX and How We Talk About It!

Thus, hopefully we, as a community, will all use this type of article for inspiration. UX can be integrated with Agile. You WILL fail along the way, but you will also learn. The more that information, stories and tips like this become available to us, however, the more we’ll be able to learn and the less we’ll make the same mistakes. Maybe, just maybe, we’re on the right path. Thanks to Johnny Holland and Jeff for starting us off!

Issues with Agile, UX and How We Talk About It

Published on October 13, 2010

As a UX designer, I’ve been working in agile development environments for almost 4 years. I know that might seem like a long time since agile still feels new, but I had a great learning opportunity when I was introduced to it back in 2007. At that time, I, as well as other UXers in the company, were constantly trying to understand, practice and tweak the ways that UX was a part of the “system”. I found my experience to be hugely rewarding and I would recommend the approach that we took to almost anyone.

These days we’re pretty lucky in that there are a lot more people doing agile and doing it well. We have groups such as the Agile Experience Design meetup that bring speakers and presenters in to talk through the methods and tools that make them successful. This has been a big win for experience design as well as the agile movement overall.

Over time I have been to this meetup and other meetups and discussions around the topic. The speakers are usually very knowledgeable and do a great job laying out the tools that one needs and the things one can do to find success in their agile systems. I have, however, noticed a trend in these discussions. Overall, no matter what meetup I’m at, or what knowledgeable expert I’m talking to, I consistently hear the same line. That being something along the lines of “Here are the tools you can use in Agile and you’ll need to determine what scenarios call for which tools. Sometimes you use this and sometimes you use that. Agile is flexible, yadda yadda.” Ok, I get it, and I agree. But I feel like there is a big gap in knowledge here. How does one determine what tools go with what scenarios? More simply, how do I know what tools to use when…. and how do I make the right decisions for using them. What is the process of determining the right tools?

In these discussions, it seems like we are just supposed to know. For example, here is a new deliverable called a half-wireframe-half-sketch-half-documentation-thingy-guy. You might need it, you might not… it all depends… then we move on to the next topic. I’m going to argue that in order for UXers to become completely comfortable with this methodology we need to talk more like “here is a new deliverable called a half-wireframe-half-sketch-half-documentation-thingy-guy. You use it in scenarios when there is a need to quickly and visually document the interaction, but not a need to capture the visual treatments at this time. You will also need it when you are passing along the work to offshore developers and testers. I wouldn’t necessarily recommend it for executive sponsor sign off, but if you find that your sponsor does bla bla bla go for it. and etc”.

This now turns the information into usable and digestible pieces. Here is the theory, here is how we apply the theory. Basically talking in this regard allows the listener to embrace the tool and empowers them to use it to the best ability. Now, I’m not calling for hard fast rules here. I get, and love that agile is ever changing and flexible. But by establishing some sort of knowledge transfer when we talk about our successes we are providing a foundation for others from which they can create their own flexibility of tools and processes.

So, in short… can we please change this discussion? The next time you get up to speak about or go to listen to an agile and UX talk, talk about how we actually use these tools and more importantly how we go about making the determinations for use. This will allow us to pick up our pace when it comes to this newer system and help us to better integrate with our development partners… thus leading to products that more closely follow our designs and are ultimately better for our users.