Archive for the 'Process' Tag

From 25 User Experience Videos That Are Worth Your Time:

In this half-hour session held at the IA Summit 2008, Leah Buley of Adaptive Path shows what it means to be a UX team of one by telling her own story and recounting a real-life example. Leah explains the concept of generative design, which is the process of creating and sketching a lot of different ideas and then refining them. The slides are amazing because Leah drew them by hand.

I just recently appeared on a panel talking about Agile development and User Experience, the benefits and the pitfalls. It was fun to have a discussion with people of other thought processes about agile and waterfall, but I’m a huge proponent of doing development and User Experience this way.

My first experience with Agile was April 2001, and I’ve run several projects with it since. That original project was as Product Manager for Escrow.com, and we ran iterations for almost a solid year (close to 20 iterations or sprints).

The result? A profitable company with a profitable product.

Three of the projects I worked on went by the wayside. There’s no accounting for issues with company culture. However, five others, including Escrow.com, launched successfully and have had varying degrees of business success. Agile doesn’t guarantee a breakthrough product, the hope is that it removes development process as a risk.

This first thing I’m going to do is define Agile development so we’re all on the same page.

Agile methodologies, or cultures, generally have the following:

• Short development cycles of two to four weeks and are usually called iterations or sprints depending if you’re using Scrum or Extreme Programming.
• Almost daily communication through short meetings, called standup meetings. They report what you are working on yesterday, today and tomorrow so any issues can be discovered early. The purpose of the meetings is to encourage further communication offline. Therefore, meetings are short. If you’re going over 15 minutes, it’s too long.
• Development progress that is measured through what’s called burndown and the product backlog.
• Clients, or product owners, that are intimately aware of progress and prioritize based on product needs. Everyone has a voice in what the product is.
• A process that is adapted to the team. They own the process so they get to use elements that work for them.
• This is key: people who are upfront about their responsibilities and don’t hide their roadblocks.

It’s also key to note that I used the word “generally,” because the process is defined by the teams that use it. So, some may only use elements of Agile and Scrum.

I’ve seen Agile work well for products that require constant improvements, but it’s hard to adapt it to a new development unless you have some time to adjust the process while people are learning. Short projects of less than a month make it hard to do a scrum-like process. I can’t imagine using Agile for a hardware-based product.

But for the web, where everything is changing, it’s great.

Here’s how to convince most User Experience teams that Agile can work:

You get direct access to the developers

One of the major complaints I have about most waterfall environments is that once you write the functional requirements and wireframes, you’re pretty much done. Developers push back, you miss 25 to 30 percent of the requirements because you just didn’t know or no one read your requirements, and there’s always the, “Well, that’s not what I meant” misunderstandings because there was a different interpretation of the wireframes.

I’ve run a Scrum-like process over the phone (I’m doing so for a current project), and the main purpose of the methodologies is to encourage more communication; with daily meetings and constant touching, you usually can walk over to the developer and ask to see the work.

If there’s an issue of the design not working the way you want it to, you can negotiate with the developer to build it in a way that achieves everyone’s goals.

While you don’t get to do as much research, what you do get is to see your work in action sooner

Waiting three months until you see your work turned into real software or website development? This is the process for you. The rub is that most of the time, you’ll get to do two weeks to a month of research at the very most before developing wireframes, or user stories, and that’s okay. Unless you’re inventing the new iPhone, why would you want to do that?

Usually you develop a lot of areas with stubs (i.e. “We’ll do that later, but just put a page there.”) and concentrate on the big functionality. Your initial stab at what to build is called sprint or iteration zero, and in most environments you’ll stay one iteration ahead of the developers. This gives you a little time to move and adapt; and, in some ways, it doesn’t allow you to over think a feature.

From Agile Product Design:

User experience people working on Agile teams become masters of development time travel, nimbly moving back and forth through past, present and future development work.

You’ll see your work as they build it, and you’ll also spot issues in days instead of weeks.

Agile doesn’t mean no requirements. It means requirements that work for the team.

Since the team decides how to build the process, that means the requirements can take whatever form the team wants them to take. If you can’t do wireframes or HTML mock-ups that fast (I can), then this process will be a tough learning curve. However, one of the panelists had a great idea: go to another website that has approximate functionality and copy it, beacause how many times do we need to redesign a lost password process?

I’m a big proponent of the whiteboard or throwing the wireframes up on the wall in printed format; talking through a feature instead of looking at it in a PDF is a much more effective way of communication.

To mitigate direction issues, what I did was develop a really high level style guide to make sure we had a holistic view of the system, then did not annotate wireframes. The developers knew just the form or text elements; and if they had a question about functionality, either they asked about it in the stand up meeting or contacted me separately. Occasionally, I was diving into the code myself to write error messaging, which was okay.

Sometimes, it’s not what you communicate but what you don’t have to communicate that makes all the difference in the world.

If there was particular communication that we felt wasn’t needed, we would cut it out of the process. Who  reads all the requirements, anyway? Usually just the User Experience folks do, while arguing with the developers. That’s an important distinction. If management is forcing something down on the team, Agile isn’t going to work. It’s not about the tools; it’s about the people using them.

If your initial pass doesn’t work, it’s not stuck in the final product.

While there’s not a lot of time for formal testing, there’s plenty of time for guerrilla usability testing. That means you have to bring in or find some test subjects to throw against your ideas. This does not mean you should write formal reports, (there’s not enough time for that) but it does mean you should do enough testing to make sure your product is going in the right direction. You won’t spot every issue, like rocks and sand: you’ll catch the rocks and have to worry about the sand later.

It allows you to fail quicker. If there’s something you spot that’s really, really off-base, you can propose to fix it in the next iteration.

The other members of the team may agree. I’ve pulled features in previous environments without serious implications, and all we lost was a week’s worth of work or less.

Smart Agile teams also pair user experience designers with quality assurance analysts to write test plans for test-driven development. Developers would recieve test cases even before they started development so they knew what they were aiming it. This is great, because QA is one of the best groups of people to do usability testing on. They spot potential issues even before the developers do.

On a few projects that I’ve been on, we saw a 50 percent drop in defects reported and had fewer reworked features.

That’s huge.

You can see progress almost immediately.

One of the biggest frustrations of working in software development is waiting for something to be built. Agile takes away some of that frustration because instead of developers waiting until the last three weeks of a three month project to show results, developers can agree upon delivered features after the first iteration.

This creates a sort of washing machine effect to gathering requirements  and software development. You keep moving toward a common goal of building the final product. Instead of seeing huge leaps of functionality with possible huge leaps in missing the target, tasks are built in bite-sized chunks so you have a better idea of meeting your goal. You also get an idea of whether or not your estimates for building the product are on base, and what you have to adjust before.

It’s about making it to the finish line, one inch at a time.

The 80-hour workweeks are gone… sort of.

One of the rules we had at Escrow.com is that no one worked over 45 hours a week; and if they did, I kicked them out of the office. Two similar projects that I worked on had the same approach.

This was very important from a few standpoints:

• Developers and User Experience designers without a life are angry people.
• Tired developers are ineffective.
• Estimates only are effective if there’s a decent control mechanism.

The main benefit was getting a true gauge of process. How many have been on projects where the developers worked slowly until the last month, then crammed a bunch of hours in to the get to the finish line? How good was that product, really?

Doing estimates well is essential to Scrum and Agile, because then you can accurately decide what’s important and what’s not.

At BidRx, only after we attached Scrum did we get an accurate assessment of what was possible from a User Experience and Development standpoint in a sprint.

That means that developers and user experience designers have to have a good idea of what they can produce within the framework of a normal workweek. Being wrong the first couple of sprints is fine, as long as you can get closer each time. Remember, it’s about attaching iterations to the process as well as the product.

Your voice is heard, period.

One of the greatest things about Agile development is that everyone has a voice. That means that if there’s something you don’t like in the process or the application you are building, you can express your opinion instead of being on the other side of the wall from the developers.

There’s always a user advocate in the process of building the product.

The conculsion

Agile isn’t for everyone; however, when it does work, it works well. It does require a different mindset, and there are flaws to overcome.

Random Thoughts mentions the following downfalls:

• Loss of the holistic view of the system
• No time to prototype everything before development starts
• Lack of extensive requirements
• More development teams working simultaneously, same UX resources
• Fast delivery means less time for testing and iteration
• Loss of time for user research projects and general research and development
• A need to track UX worth and work before a project is completed

I only agree with the two that are in bold. That said, we have to try something different, because waterfall isn’t working.

Some other links:

• Scrum Club
  
• Agile UX

Blog posts:

• 10 key principles of Agile Software Development
• Twelve emerging best practices for adding UX work to Agile development
• Jacob Nielsen Speaks (Because he’s selling something)
• The missing piece: how interaction design can add to Agile

Disclosure: I’m a Mac user. I’ve been one for over 18 years. But I don’t drink the koolaid.

Every time I change jobs, I usually start doing wireframes in a different application. One place I worked at, their language of choice was .NET; another place, it was Java.

On a message list I subscribe to, someone put across the usual, “We want to make the case to get everyone Macs and convert from Visio to Omnigraffle.” Now, I’m all for feeding the Apple obsession as much as everyone, but the religious wars are over.

Tools, schomools. If it looks like a hammer, use it.

Here’s a few reasons why I think the whole tool argument is pointless:

You say tomato, I say tomato

Most of the applications are close enough to each other in feature sets that it really shouldn’t matter much. Other than a few random features here and there, Visio and Omnigraffle are so close that Visio files import cleanly, and some of the templates each use are identical across platforms down to the annotations.

My clients can’t tell which wireframe or site map came from which program, and I seriously get very few requests for “Ya know, this looks like a Visio file.” They do say, “Nice detail.”

The same arguments go on in software development regarding Java and .NET, yet semantically, they’re almost the same. Most Mac and PC Programs are identical.

Why start a religious war when you don’t have to?

We should be familiar with all the tools

I know, some of us had a career before the web, and mine was print. I used to work in a service bureau, and had to output print files to film (remember printer’s film?). Occasionally, we had to fix something, so that meant I had to have enough familiarity with the programs to use them at a competent level.

Because of this, I’ve probably used over 30 graphic programs to open files, fix files, and design work. Remember Aldus PhotoStyler? CorelDraw? Macromedia Freehand? CricketGraph? I do. and I’ve used everything from Quark Xpress to Adobe InDesign to get concepts across.

Our job is to know software and how to communicate; consequently, we should be able to figure out how to use the programs despite their usability issues.

It’s about getting the idea across, not about the tool

I’ve never had a client say, “You know, Omnigraffle is the best way to do this.” They always were, “We just want the results.” While we all have our favorite tools, it’s not about the tool, it’s the process. If that means jumping between Microsoft Word to write a report to Visio to build a wireframe, that’s what it takes. One of the other IAs I know uses PowerPoint. I would never use it, but she has made it work with tons of clients.

The ideas behind the wireframes are what’s most important: I’ve seen information architects that generated the worst looking wireframes be some of the most effective because they took the time with the client or the developers to talk through the issues.

If it works on butcher paper, and the client is happy, butcher paper it is!

The takeaway — it’s what the team prefers

If you are that much in favor of one platform or program over another, fight for it. If you’re the only person there, you’re going to pick your tools usually.

But if you work on a team, consider how everyone works together before you advocate something. Just because you have a personal preference, someone else might not feel the same.

I think one of the hardest parts of explaining the User Experience process is how it fits within into the complete software development life cycle, especially in a consulting environment.

Clients want to know how to limit costs, developers want to know when they’re going to get in documentation, and your boss wants to know what you can bill for (remember, wireframes are deliverables). Some of the process is very new for developers that have been working in software for a while. Or, as one CTO said to me, “You know, you guys changed the process on me.” And he had worked in an agency environment. And I had just recently worked with a couple of agencies that know they needed to start paying attention to it, but didn’t know where to start.

This is a document I developed at my previous company to explain the User Experience process not only to clients, but internally within the consultancy, and it helped greatly show that we were following some kind of process (Well, I tried to, but you know how that goes on some projects).

I included where sales came in, to further illustrate the point that User Experience extends even into the sales process because a good Information Architect or Creative Director can sell the concept, and a final review with the developers, to fix issues that came up. A lot of consulting engagements lend themselves to a waterfall process because of fixed costs, so that’s what this is modelled around.

What’s the process you follow at your company?

This was a thread over at LinkedIn, published in CIO. My submission is number three.

Here’s a few of my favorites:

• When you see the project budget, you realize that over half of it was spent on a Web designer to create a Photoshop mock-up of the home page—with no regard to whether that design is feasible. Or with any attention to the thousands of pages of content that will exist underneath that home page.
• It is a big project and is named Project Iceberg. Or it’s the third time the company is trying to pull this off, and the project is code-named “Phoenix.” Somehow, you don’t believe this one can spring from the ashes.
• The manager of your mission-critical project (handling 80 percent of the company’s revenue) has three months exposure to the technology of choice, and is training four brand-new developers at once. The manager is given a three-month project deadline.
• Management decides to spend a million dollars on a $20,000 project. Then the managers start agreeing with computer company salespeople that the $1 million in software requires $2 million of hardware. Meanwhile, a secretary purchases an off-the-shelf PC and a shrink wrapped CD containing some new office automation packages. She implements the project during her lunch break. (Arguably, we should count this one as a success.)

Most clients think they know their business and when they approach User Experience professionals, they’re anxious to get wireframes cranked out. How do we get clients to take a step back and engage in strategic type activites to optimize their technology solutions?

For me, this didn’t happen overnight. I stopped obssessing about whiz-bang interfaces and took an active interest in helping clients think about design in terms of return on investment. Because I always spoke my mind and articulate ideas in terms of how they drive the bottom line, clients began to include me in strategic meetings. Below are some of ways I incorporate strategy focused activities into my process.

Propose the Value Proposition

When I first consult with new clients about a project, I let them know that analysis and research are an integral part of my process. It allows me, the UX designer/Business Analyst/IA Minion to understand their business from the inside out. I explain that analysis, interpreting metrics, product roadmapping, etc. can optimize return on investment. By interpreting indicators on usage patterns, we can pinpoint what’s not working and leverage winning features. The result is a cohesive product vision that differentiate the client from their competitors.

Speak About the Project in Business Terms Not Usability Goals

Articulating your design in business terms is a great marketing strategy. Before my first formal meeting with the client, sometimes even before the contract is signed, I always conduct a quick site audit. This gives me a fresh perspective before I know anything about the project and clients love a fresh perspective. I record my impression on branding, business objectives, and how well the design and implementation drive the business objectives. I always think in terms of return on investment. This gives me fodder to speak about the project in business terms as opposed to design terms. Incidentally, if I get the contract, I bid the hours I spent back into the job. If I don’t get the contract, then it’s good PR.

Request for Quantitative and Qualitative Data

Request for reports at the first meeting. Be prepared to explain what trends and patterns you hope to discover or why you want look at data for specific feature sets. If you don’t yet have an idea which reports you need, tell the client that you will email a list of reports that you want pulled. This lets the client know that research is an integral part of your process. It the project is a start-up, conduct topic and keyword research to define search volume. For qualitative analysis, inquire to see whether any surveys or focus group testing have been conducted and what the findings were.  Finally, ask the client how or if the business has responded to the results from analytics and surveys.

Prioritizing Requirements and Use Cases

Don’t be a gatherer of requirements. Be an expert. When conducting interviews with stakeholders, don’t just gather requirements. Work with clients to prioritize requirements and use cases based on business objectives and the research that you’ve conducted. You may propose new requirements to refine and simplify workflows.  Always couch your input based on business objectives and the bottom line.

Use Business Objectives, Usability Goals/Strategies as the Measuring Stick for Your Design

I always preface wireframes with business objectives and usability goals. Clients gets sick of this after subsequent meetings, but they learn quickly to evaluate wireframes based on the real business goals. This is also helpful when your wireframes are circulated to other team members, because the business objectives and usability goals is a reminder of the foundations of the project.

My job is changing.

I can already feel it.

It started last year when I began getting interested in analytics, but it’s really transforming. now. I’m not a web analyst, nowhere near. But more and more clients are hiring me to help with product roadmapping. More and more, I’m looking at product design and marketing strategy from a chicken and the egg perspective.

Recently, for several projects, I’ve started with the analytics, the traffic, the market research, search volume, then work backwards to define the solution, the return on investment. So I have the egg, I have to figure what kind of chicken lays that egg.

Usually, clients will build a solution, then develop campaigns to drive traffic to it, but lately, I’ve been getting projects that are reverse. It’s not, “If you build it, they will come.” It’s more like, “They’re here. Now build something that they need.” I’m not just designing some test feature. I’m designing actual new sites with little more than a domain name as a requirement.

My role initially, is to conduct excersises with my client to clearly define the following:

1. Market sector
2. Value proposition
3. Business Objectives
4. Strategy and brand for the user experience
5. Marketing Strategy

After this excersise, my goal is to have a mission for the user experience, because a deep user experience will brand the solution. At heart, I’m still an interactive designer. It’s what I love to do. But building a sound business foundation for your design is critical to its success. If you don’t do this, then if you build it, they will not come.

I don’t know about you, but every time I’ve done the “hey, lets do the requirements gathering in a waterfall process,” by the time we get to the bottom of the waterfall, we’re nowhere close to where we started. That’s one of the reasons why I’m a huge fan of agile requirements gathering and software development.

Horse Pig Cow has a great post on the waterfall vs. the washing machine. It’s done in a presentation (I’m going to include it below).

| View | Upload your own

Some of us work for in-house UX groups and others work for agencies. Having been both an “innie” and an “outie,” I can vouch for the fact that I learned a lot more during my experience working for an agency. Here are the pros and cons.

Pros:

1) The variety of projects makes the work interesting and keeps you on your toes. You never work on one project at one time. You juggle multiple. You learn the nuances of many different kinds of technology and use models.

2) You sharpen your ability to think strategically in your design approach as well as selling your ideas. Since you are presenting your work to new stakeholders on a regular basis, you must justify design decisions with usability goals, business objectives, and/or metric indicators. Everything you put out there has to be polished and your best work. It’s like being a new employee every couple week and you have to prove yourself to a new set of bosses.

3) You learn to work and adapt with many different organizations and teams. Every organization has a different working style and organizational structure. That affects communication and approvals. This requires that you are quick on your feet, since you’ll be constantly drilled by clients. Even when they love what you do, they still drill you.

4) You become a walking encyclopedia of the best on the web. Because of the variety of projects you are exposed to, regular research and analysis are part of the job, even when you are not on the job.

5) Shorter time lines means quicker decisions and launches. After working at an agency, I get impatient at how slow decisions are made and how long it takes in-house groups to develop.

Cons:

1) Lots of pressure to always deliver the best work. When large companies pay tens and hundreds of thousands of dollars, they expect you to bring your A game and think outside the box EVERYTIME, so the pressure is intense.

2) A shorter time line and finite budget creates pressure to be extremely efficient. Agencies make their money by being billable, therefore most of your time should be billable. There’s little down time to try out different ideas. Also, when companies hire an agency, they need it done yesterday, so you’re expected to be super creative at breakneck speed.

3) Pay is not as good as working for a large corporation with an in-house group.
I no longer work for an agency, because now I can charge more working for myself. However, I think the experience is valuable. I’m so glad that I did it. Best learning experience I ever had.

MOSS projects for a number of reasons, and it’s usually not the tool. (And only know this because with proper planning and design, our clients have raved about what a good product it is.) SharePoint can do great things when it’s used for what it’s designed for i.e. if you want to nail a nail, use a hammer, not a screwdriver. It’ll be ineffective if you use it like using that screwdriver.

CleverWorkarounds has a good article about it, comparing it to a drinking game which I think is classic. Again, it’s not the tool. They also have another article about selling MOSS that’s pretty “interesting”.