Designing in Agile: Fighting for the User

Project Goal

The Revoke Access project goal was to build an application that would allow Human Resource representatives and Managers across Comcast to remove an employee’s access to internal applications, email and building access.

This was a brand new application to be designed for both desktop and mobile.

My Role and the Project Team

My role was as the UX designer/researcher on this team conducting usability testing, QA defect testing, creating user flows, low-high fidelity wireframes, and prototypes. The project team included developers, a product owner (who also served as a Scrum Master) and functional team QA. 

Initial Flows & Designs

Working with the product owner, I developed some screens based on the initial requirements.

In my conversations, I determined that there wasn’t clarity in the different user and process flows based on how HR and the managers would interact with the application. A few issues included:

• HR and Manager had different access points (IA).

• Other applications were going to be accessed through the application. This came from the idea that eventually some e-forms (termination/severance) would move to this application.

• Mobile would not allow access to those e-forms.

I created a flow for each scenario calling out the interactions in getting to, through the and if the user made a selection outside the application.

Usability Testing

Usability research and testing is not something that has been built in the culture of this department. There was a push to move forward with the design, but I insisted on doing some usability testing. I met with three current managers and received feedback that helped with:

• Making the interactions clearer (dropdown placement)

• Adding features such as a rationale for revoking an employee

• Creating wording that ensured someone was going to act on the request

Changing Requirements

The requirements were initially set as described in the project goal, but the following were added throughout the project:

• Need to have an employee to be granted access again

• Ability to learn in real time if an action can be submitted

• Need to notify parties (managers and HR reps)

• Need to add attachments just in case there was background info needed

• Need to revoke someone same day or "emergency revoke"

Many of these changes could be attributed to working in Agile. The challenge was not the changing requirements as much as those changing requirements didn’t coincide with changing timelines. This put us behind in every sprint.

Fighting for the best experience

I proposed 3 options to my design team (noted from left to right below):

• Keeping it in one step (the lesser experience)

  • This is what the product owner wanted because:

    • Development said would be less work.

    • The experience didn’t seem to be that complex

• Adding it to another existing step

  • possibly a better experience but there wasn't a clear place where adding it made sense

• Adding an additional step (this was the best experience based on various factors )

  • Rather than combine all the actions I proposed separating it to minimize errors. The research shows this was the best option for various reasons.

I created a prototype to represent both the more error prone process and my recommended experience. With the additional time investment needed and the belief (against the documentation) that it would not adversely affect the experience, the product owner chose to move forward with the lesser experience.

Constraints in designing for mobile

Based on users, desktop was the project team’s priority. However, we needed to also allow for mobile usage, even if some features were not going to be available.

This was the first time there was a focus on making an application truly responsive for mobile. Until this project, mobile was an afterthought. The framework, SAP Fiori, created some design challenges as it was not responsive but adaptive. Changes to desktop would make changes to mobile. 

For example, the mobile design to the right was not what I initially proposed. My initial mobile designs had the "Update Details" button below the input field. However, desktop was designing with the button on the same row and this could not be changed on mobile.

Design changes and iteration process

Living within the constraints of changing requirements and designing for a lesser experience, I iterated through the process with my design colleagues and tried to simplify the experience as much as possible.

I designed this interactive prototype for the development team to drive the build.

Lessons Learned

For every project there are lessons learned and aspects that can be done better next time. Here are a few from this project.

More usability testing

Overall, there was too much reliance on the product owners and what they believed worked for the user. More usability testing could have made this application more user centered and potentially minimized (or at least focused) the features.  

Working to collect requirements early and thoroughly

The product owner and senior advisors implemented a number of changing requirements throughout the project. Looking back, I would have been more involved with trying to talk through all the potential requirements early on and clearly explaining how delays would adversely affect outcomes. As the requirements changed, I realized that I would have gone a totally different way with my design.

Compromising for delivery

I pushed back to create the best experience consistently. Yes, I would have wanted a better experience for users and will subsequently battle for this and other applications we build to be more user centered. However, learning to compromise is a core piece to delivering a product. Push where you can; make incremental changes and live to fight for the user another day.