Step 3 – Build It
This is the Sprint and belongs specifically to the Agile/Scrum process.
Once a Sprint begins all required mockups and/or prototype screens should be completed (No creating mockups during the Sprint). Since the developers are part of the initial review of the mockups there should be no UX surprises. The mockups/prototypes are reference documents for each of the associated user stories. One rule that we follow is that the user story is the “final-record-of-truth“. If there is any discrepancy between the mockup and the user story – the user story wins. The number one culprit of this is content or label changes. Often times the language of the content will change right up to the last minute before sprint planning based on the Business input. We don’t expect our mockups to be pixel-perfect so we defer to the user story for last minute content or label changes.
There are however technical surprises all the time and that is what the little blue loops in the graphic above represent. Thing pop-up and you have to be able to adjust on the fly.
We also utilize sprint playback sessions to make sure that the developers are implementing the designs as agreed upon. This is another opportunity for slight modifications or tweaks to the mockups but often times these changes can be verbally communicated and captured in the user story.
Slight tweaks or modifications to the mockups/prototypes are acceptable during the sprint but if there are larger development issues with implementing the design then we have two options.
- The user story is removed from the sprint until the mockups/prototypes can be adequately updated. I’ll admit that this is rarely done because the development team’s velocity would be significantly reduced if they remove the story and don’t have another story with the same assigned points ready to takes its place for that sprint.
- The other option is that the product owner and UX team will agree to implement a functional version of the design for the current sprint and create a new user story for the backlog that captures any UI or UX enhancements that should be implemented for a future sprint. This can really help build trust within the team as it allows the development team to stay on track for their sprint commitment and UX can work with the business and product owner to take the UX enhancement story in for a future sprint.
We believe that UX should never impede development but we do request that our recommendations should always be captured in a user story so that we can prioritize those recommended changes for a future sprint. This is where the relationship between the Product Owner and UX lead is critical to negotiate these compromises.
What is done?
- Ensure that New Features use Established Reusable UI Patterns – We use a UI Library that is specifically for developers.
- UI Checklist – We have a created a UI Checklist for developers to refer to for standard UI patterns. This is basically a slimmed down Style Guide. How useful is this? Honestly it’s something we have to constantly remind our development teams to use and we rely more on the UI Library than the checklist.
Who is involved?
- Scrum Team
- UX resource
- Normal Agile/Sprint
Step 4 Feedback
After the project is in production the next step is to incorporate feedback from our users and business stakeholders to drive iterative improvements to the project.
What is done?
- Usability Metrics – One of the key areas that helps us in an Enterprise environment is that we have specific time measurements on the amount of time our users spend on each screen. This can help identify bottle necks and possible usability issues. One area we plan on exploring is to baseline current productivity metrics so that we can show overall increased value after new designs have been implemented.
- Gather Business / User Feedback via user forums and interviews – We have various user groups that we stay engaged with to hear about issues that users are having. Most of the time these issues are centered around business complexities rather than specific UX issues. Its still good to be aware and identify if there can be some UX improvements to help the users. We also rely significantly on our training team to help consolidate issues users are having in the field. Our training team is a great conduit to our users and we rely on the heavily!
- Update or create new Mockups and Prototypes based on feedback – this is where the fun begins. Let’s take what we’ve learned and improve the UX for our users for both current features as well as new projects that are on the road map.
- Validate new Hypothesis Solutions – Always learning – Always Validating New Ideas!
- Update Backlog with UX related enhancements – This is where UX starts to build that full circle engagement with Agile. Now, instead of UX only responding to new requirements we are establishing our own requirements. This is where the UX lead can leverage their relationship with the Business stakeholders to help drive up the prioritization on these new UX specific stories. Getting Business buy-in is a huge step in pushing UX forward in an Enterprise organization.
Who is involved?
- User Feedback
- Training Team
- Business Stakeholders
- UX Resource
After release/ Ongoing engagement with users / Output should feed backlog