UI/UX in an Agile Development Environment

Question

I'm working with a company on a medium-large scale web application. The application is to replace existing applications, manual, and electronic processes. This project is on a tight deadline, and is being developed in an agile environment.

Another thing to note about this application, is that the industry/company that it is being built for is very new to me, and there are relatively few modules/applications that I am familiar with. By this I mean, I know there will be a finance section, and an employee tracking section, and I have a pretty good idea of what to expect for these requirements. However, there are also many sections/modules to do with genetic cataloging, DNA testing, and large registrations/application processes with an abundance business logic build into them.

My question is, how as a UI/UX designer does one plan for building an application of this size/complexity when they are unfamiliar with the majority of the applications/processes. As I complete modules, they are being passed off to developers, and I keep causing issues when a new module comes my way, and I have to change existing framework/design to fit them in.

How can I avoid this? Any suggestions? What are some best practices?

Answer 1

First, you are not causing any problems, you're doing the best you can with what you have and asking for help shows you have a good head on your shoulders. So I won't sugar coat any of my answers otherwise I don't believe I'd be doing you any justice.

First, throw out the term agile. I've been in the environment you are in and they call it agile because they don't know any better. Agile doesn't mean fly by the seat of your pants and hope for the best. Agile means, doing the thing that is the best use of your time dependent upon where you are in the project.

Second, you are heading into a train-wreck. My suggestion would be to pull the emergency brake now. You may worry about getting in trouble, but don't. Just be cool about it and you'll be fine. Ask questions and get clear answers. Keep asking until you're happy with the answers, but be cool. Copy all the relevant personnel on your emails, but be cool.

If you can't see the light at the end of the tunnel something is wrong. The only way an agile environment works is if everyone is on the same page with a clear cut goals and objectives. You should have a general game plan in place so you know how to treat each piece and how it fits into an overall framework. No piece should be a mystery.

OK, so if none of this works for you, here's what you do. Look ahead, put in the extra hours and figure out your own game-plan. Honestly, even if the train does come to a stop, look ahead and figure out the best path. Do your own UX Research and find a set of interactions that can be used for the rest of the project as a whole. Re-use as many elements as possible without sacrificing the integrity of the site.

Here's a link to get you started.

You'll have to simplify in order to get through.

Best of luck to you. If you get a chance, drop a comment, I'd love to hear how it turns out.

Answer 2

On Agile

From the various Agile-related concepts, I'd like to highlight two:

• It meant to combat requirements volatility (frequently evolving or changing requirements or their priority).
• It increases time to market.

Agile, when used in the right context (and followed by the word), is nothing short of magic. The cost of changes within a properly managed Agile project can be dramatically lower compared to the waterfall paradigm.

But Agile is not a catch-all solution (what is?), and sadly it is often seen as a silver-bullet that will always work. The reality is far from that.

On requirements engineering

It has been known for years that the sooner a requirement is accounted for in the production process (Requirements, analysis, design, coding, unit-testing, deployment) the less costly it will be to realise - changes are cheap at the beginning of the process, very expensive at the end.

This is something that every software/UX designer will testify - the more of requirements you know of before the design process, the more solid the design will be.

There seems to be a contradiction here - on the one hand, Agile preaches to short iterations of highly limited scope (including what requirements are accounted for); on the other, the more requirements you account for, the better the designs.

The 3 design strategies

There are basically 3 design approaches (UX or software):

• Throwaway (revolutionary)
  • When you have little understanding of the problem and requirements (high level of uncertainty)
  • You design quick, test quick, and mainly to learn what works and what not.
  • Normally a super-quick process, but designs are likely to be discarded (leading to redesigns or rework).
• Evolutionary
  • When you have some understanding of the problem/requirements, but it is incomplete and likely to change.
  • You build the design step-by-step, accounting for new knowledge in each iteration.
  • Designs typically serve as basis for next iteration.
  • With each iteration the previous design often requires revisions - sometimes dramatic ones.
  • The danger is that bad designs may persist.
• Incremental
  • When you have clear understanding of the problem and requirements.
  • You design to meet all requirements.
  • This process can be long.

When Agile is great

Agile is great for a project where you have either no or little understanding of the problem domain. For a completely innovative project, the throwaway strategy is often used; however, most Agile projects use evolutionary design. An incremental design is generally anti-Agile.

What is important to mention is that using Agile must come with the realisation that your current design may not fit future requirements. It's what you've signed for by choosing Agile! This is why code refactoring is absolutely vital to the success of an Agile project. In Agile terms, you knowingly deliver just enough; nothing more. It will work for now, in the future revision are likely.

When Agile is a disaster

When you have a clear understanding of the domain problem and requirements. You'd be generating a lot of waste and rework by not accounting for these from the onset, and by not taking the longer, non-Agile incremental design.

Quite a few companies have a clear understanding of the problem - the system has been there and used for a while, with all functionality in, but usability is low. So it'll be rather dubious to ask designers to ignore evidence, just so the work can fit into a 2 week sprint.

Suggestions

To begin with, it may be the case that your peers are trying to eat the cake and leave it whole - you can't be asked to produce optimal designs unless you are given the time to look into all requirements. The concept of just-enough-now-iterate-later is key to Agile.

Then, you can obviously try to look more laterally on other parts of the system so at least to get some idea of what is ahead.

But all in all, I'm sorry but I don't think it's fair to ask someone to do iterative design that by definition does not account for all requirements, then complain that the design needs changing because it doesn't account for all requirements.

Answer 3

I think the industry has reached a point where UI/UX design needs to be done in a way that is both holistic and also systematic. By this I mean that companies looking to develop new products and services in the digital channel needs to invest time and effort in a design framework or a similar structure that allows you to combine the visual, content and interaction designs so that it is consistent and aligned to the company brand.

For some examples of this, look at the Google Material Design page as well as the Atlassian Design Guidelines. It provides both the high level design approach as well as the low level UI components and rules to help people developing applications using their style and patterns. Unlike the Apple and Windows style guide, these documents are both living and also more interactive so it captures all the essential elements of the design in one place.

Answer 4

If you can get access to people, I'd spend an afternoon chatting to users to understand what the system is suppose to do.

Answer 5

Users are not just the (for lack of a better term) end-user of the system. There are many other users involved: developers, business, as well as end-users.

Talk to end-users about the existing product, discover their pain points, needs and goals. Use this information as your leverage. Prototyping can help quickly vet ideas outside of the dev cycle. Prove your design hypothesis without development impact.

Talk to developers, understand the technical limitations. Technology, especially in an enterprise, has loads of constraints and usually specific methods of solving problems.

Talk to business leads. Learn about their vision of the future. Uncover why they want the redesign - the real reason, not just some philanthropic jargon. Try to see their image of success.

Take these things and prioritize your battles. Try getting buy-in from the three groups then agree on the best way to communicate this (interactive protos, whiteboard, sketches, wireframes, specs, etc.). Use whatever method works for you in your environment.

As soon as you have a couple wins, you'll be amazed how the atmosphere changes in your favor - and ultimately your users favor.

Good luck, keep at it! K.