Menu
Menu Sheet Overlay
Search
Search Sheet

Sprint-Based Design Process

In this section understand how Mobify uses a sprint-based design process to deliver builds fast.

Sprint 0

At Mobify, we consider the Design Phase as Sprint 0.

The subsequent sprints are typically structured around building a key feature at each delivery. For example, Sprint 1 typically includes the global elements (e.g. header, footer, and navigation) and the homepage, while Sprint 2 may include PLPs or the Checkout flow. This will always vary based on availability of resources on your end, and client-end priorities.

Sprint Design and Build Phases
We recommend using a sprint-based approach to design and development.

Sprint Deliverables

Your role as a designer during each sprint is to complete work for the subsequent sprint. Staying one step ahead of the engineering team is key. During the sprint the designer is also responsible for answering questions, solving edge case issues, and completing a design pass to ensure the implementation matches the proposed experience. Typical sprint deliverables may include:

Updating Documentation

Keeping your documentation consolidated is key to establishing transparency with your team and ensuring that information relevant to the project is accessible and digestible. Here are a few areas that you’ll need to curate frequently:

Project Learning Outcomes

During the course of several sprints you may come across a scenario or discovery during user testing that may hold project-wide implications. Sometimes these may affect the UX goals and aspirations you may have discussed with the client during the discovery phase of the project. Log these learning opportunities and be sure to include them in your project retrospective. For example:

During user testing our checkout flow, we discovered that the ‘Continue Checkout’ button was not immediately visible or easy for users to locate.

Customer Provided Testing Elements

Keep a consolidated document of client supplied log-ins, coupon codes and payment methods. Your team-mates will thank you, especially your QA staff.

Keeping a Decision Log

Maintain a simple spreadsheet of key decisions that you’ve discussed with your client and the outcomes of these individual decisions. This should be detailed, right down to the date and method of resolution. For example, if a client requests a layout change to a page, log the nature of the request in addition to how the matter was resolved and when. For example:

August 26 Customer requested that we change the mobile layout when the device in landscape Resolution: we implemented a two column layout versus the single row layout and the customer loved the idea

Performing Design Passes

As each sprint progresses, you should be doing a regular check-in on the progress of a build to make sure that the site is being built just as designed.

How you do these design passes is something you’ll have to decide with your team. Will you, the designer, need to approve every feature pull request? Or wait until the end of the sprint and record your feedback all at once? Talk to your developers and decide on a plan that works best for everyone.

Be Pixel Perfect… Almost

While you’re making sure that the designs match your mockups, you should also be aware that every browser — iOS Safari, iOS Chrome, Android Chrome, Android default browser — will interpret CSS slightly differently. Don’t sweat it; embrace fluidity. Just make sure things are using the right values, and that the overall tone is correct.

Sprint User Acceptance Testing (UAT)

After each sprint, a bundle with the in-progress project will be passed back to the customer to review. As in the Design Phase, they may have feedback.

Before any of it is implemented though, the designer should have a chance to review it. This allows you to catch any changes that may negatively impact the user experience. If needed, you may want to respond to the client with alternatives. Use your decision log to capture these discussions and their outcomes.