Matt Lambert

Check out my blog, or sign up to receive articles by email.

Agile Design

By admin on August 17th, 2014 in Agile

If you’ve ever worked on a development team, you’ve probably worked using agile software development. If you’ve never heard of agile it’s essentially a responsive way of developing a product. You don’t focus on doing things in a sequential manner, it’s more of a flexible process that can be constantly changing. The whole point of agile is to remove traditional road blocks and ship products faster. Check out these points from the agile manifesto on wikipedia:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

From a software development stand point, this process works really well. However, from a design stand point, this goes against what you we’re probably taught in design school or learned working at an agency. Visual design is almost always done in a waterfall process. Waterfall is a sequential flow where you set goals or milestones up front. You start on your first milestone and don’t move onto the next one until it’s complete. Agile blows up this model and doesn’t follow a strict sequence of events. How as a designer do you work in this model? For almost 2 years now I’ve been working on an agile development team and I’ve learned a number of best practices which are outlined below.

Project Requirement

Although we aren’t fully planning out the entire scope of a project from a design stand point up front, we do need to define the requirements of the project. This would include things like the key product features, use cases, and potential pain points for users.

When you’re starting a new project the more research you do, the better off you will be down the road. This can include things like talking to your current customers (if you have them), researching similar or competitor products, and talking to people you see as your future users.

Part of this process also includes defining personas for your product. Personas are fictional bios for the type of users you see using your product. As you go through the planning phase, you refer back to your personas to help guide your decisions. They are also super helpful for helping you decide on a single direction when multiple valid options are available.

During the inital planning phase you should involve some key developers, the product manager, product owner, and any other key product stakeholders. You want to involve all these people from the start of the project so you can ensure you are on the right path and large refactoring won’t be required once the project starts. Having to make big changes in UX after a project is underway is a sure way to negatively effect the quality of the software you building.

Key Feature

Once you’ve defined your personas and used them to validate your key features, you should create an agile story for each one. In some cases you may want to create an agile epic for each feature. However, I prefer to keep the UX work seperate from the feature epic out of the gate. Much of the UX work will be completed prior to the first sprint starting so it makes sense to isolate it. You may want to group all the feature stories under a single UX epic.

The questions that were answered around use cases, user pain points, and requirements at the beginning of the project should be entered into each feature’s story. Once you’ve finished writing all your stories and you feel that you fully understand the scope of each feature, it’s time to start creating UX flows for each one.

UX Flow

A UX flow are the steps required to move through a feature in your product. For example, Login would be considered a feature for any web application. You need to document things like:

  • What page does the user login from?
  • If the user successfully logs in, what page are they redirected to?
  • If their login credentials are invalid, what happens?
  • If they forget their password, where do they go to reset it?
  • If they decide to logout, where are they redirected?

These are just a few examples of the possible paths that you need to sketch out for a feature like Login. To create these flows I’d recommend using a wireframing app. There are a number of decent ones out there but I personally use Balsamiq.

Once you’ve created a flow for each of your features, you should attach it to the cooresponding story for future reference. The next step is to review the flows with the key project stakeholders and get their sign off. 


Once you’re flows have been finalized, the next step is to prototype each feature. You can do this in whatever manner you feel most comfortable with. Some people like to do this in a wireframing app but my preference is to do this with HTML.

If you go the HTML route, you should pick a CSS framework like Bootstrap to allow to quickly build your page templates. At this point, don’t worry that much about your visual design. The good thing about using a framework like Bootstrap is that you can layer a theme on top of your prototypes once they’re completed. If you’re interested in learning more about theming Bootstrap, you should check out my eBook Mastering Bootstrap.
If you’re wondering where to start prototyping, refer back to your UX flows. You should have laid out all your pages, states, forms, etc… in that phase. At this point, create a new agile task for each template under the feature’s story. Then you can start coding up your templates.

When you’re coding up your templates you should always shoot for about 80% accuracy of the final product. Why not 100%? Because this is agile and things will change when you start getting into your sprints. You don’t want to get hung up on doing things 100% accurate because it will make more work for you in the long run. You need to let go of what you have learned in the waterfall world. The actual development is agile and changing and the UX/UI also needs to be flexible. The best way to do this is to shoot for 80% correct and leave yourself some wiggle room as the project progresses.

At this point you want to concentrate on solidifying bigger picture patterns in how the UX works. Finalize how you will handle error validation and how a form will be laid out. Don’t get hung up on details like what icons you use for error and success states on a form. That can easily be changed during the project. However, having to refactor the template code for all your forms will cause a problem in the development cycle. It not only introduces a bunch of refactoring work, the reality is it won’t likely make it into the product. Agile is a fast moving process and your team is not likely going to want to go back and rebuild something that already works.

Once you’ve finished off your prototypes, you need to review them with your key product stakeholders. I’d actually recommend doing this feature by feature. Don’t prototype all the features then review them with your team. If you’ve created a UX pattern that doesn’t work, it’s much less work to edit one feature’s prototypes compared to all your prototypes for all features. As I mentioned above, you want to shoot for 80% accurate UX at this point in time. The reality is that you might not have all the requirements up front so you need to leave some room for changes as the project moves along.

When you’re reviewing your prototypes with your team, you should encourage them to not think about implmentation of the feature at this point. It’s okay to go down that road a little bit but you don’t want to let technical conversations derail your goal of solidifying the UX of your product. Once the prototypes for all your features have been reviewed and approved, you can start to think more about actual implemenation of them.

At this point, assuming all your prototypes have been approved, it’s time to close your agile tasks and stories for each feature. Make sure you attach links to all of your prototypes to the stories for future reference. You might be asking yourself why am I closing these stories if they are only 80% complete? I like to divide the features into two stories. The first is the UX stories we’ve been talking about and the second are the actual functional stories that the developers are going to refer to when building the product. You should attach your prototypes to the functional stories and then review them in grooming meetings. At that time if changes are required, based on implementation details, you should create a new task under the functional story to track the updates to your prototype. That way it is part of the functional story and must be resolved before the story can be closed. That way you are tying the design work in to ensure it is not ignored or missed on implementation.

Which sprint should I work in?

Up until this point all of the work I’ve outlined should have been completed in sprint zero. The first task that should have been added to sprint one was the functional stories. Once you’re project has kicked off and you’ve started your grooming meetings, you may have to task out updates as I mentioned. This is what you should be working on as the project moves along. From sprint to sprint you should be working on refining your prototypes based on conversations that happen in grooming.

Generally stories that are being groomed are working one or two sprints ahead of what you are actually working on. In that same respect, you should be working on refining your prototypes one or two sprints ahead of the current one. That way when the time comes to implement the work, the team won’t be waiting for you to update templates before they can do their implementation work. You don’t ever want to be a bottleneck for your team or the whole agile process will breakdown. The point of agile is to remove traditional bottlenecks and roadblocks.


Like prototyping you should aim to have your look and feel 80% complete by the end of sprint zero. It’s virtually impossible to have this done 100% because there may be components you didn’t realize you would need that come up during the life of the project.

Like I mentioned above, I’d highly recommend using a CSS framework in agile because you need to take a modular approach to your CSS so you aren’t repeating yourself. The last thing you need is multiple ways to render a table in a template. This will introduce confusion for developers and end up in a disjointed looking UI. My tool of choice for this is Bootstrap and you can learn more about theming Bootstrap in my eBook Mastering Bootstrap.

I’ve been working in the agile process for about 2 years now and even though it was a bit of culture shock up front, I’ve grown to enjoy working in this manner. There’s not a ton of good info on this subject currently available so hopefully this will serve as a good introduction for you. If you have any questions about agile design, feel free to hit me up on Twitter.


Like what you read? Check out my store over at Creative Market to support the blog and help keep the lights on. Files starting from only $2.