11

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?

Improve this question
1
  • Tight deadline and agile environment? – greenforest Oct 18 '14 at 10:10
8

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.

Improve this answer
16

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

A bar chart showing the growing cost of changes as the development process progresses

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.

Improve this answer
8
  • I registered to UX Stackexchange just to upvote this answer. – Daniel W. Oct 8 '14 at 13:59
  • When was the last project you worked on where you didn't gain experience during implementation, or hit some unexpected problem? This answer implies that "when you have a clear understanding of the domain problem and requirements" is something that ever happens outside of theory. This answer seems to me to be by someone who doesn't quite understand what agile is about. – JamesRyan Oct 8 '14 at 15:14
  • You make a valid point - you always learn along the way. But if you come to write an email client, or a tree-grid component, you should have a fairly solid understanding of the requirements. Same with projects where functionality was thrown in for a few years with no consideration for UX. New functionality is hardly added; the users have had their say; and now you need to sort it all out - breadth and depth. Such work requires time. – Izhaki Oct 8 '14 at 16:09
  • Have you ever tried to add a role-based mechanism, or a command-based transactions (for undo) in the middle of a project? Months of work would be spared if such requirements were identified before a single line of code was written. And would you apply Agile in the following projects: A ticketing system for the olympics, an air traffic control system, a system to replace the current customer accounts of an energy provider? Please educate me on what Agile is about and what am I missing. @JamesRyan. – Izhaki Oct 8 '14 at 16:12
  • Actually it should not be difficult to add those later if the app is decoupled in the proper way. Agile is not about not having a plan or spec. All of those are exactly the types of project that usually overrun, go overbudget and fail miserably that can most benefit from the approach. – JamesRyan Oct 8 '14 at 16:37
2

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.

Improve this answer
0

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

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.