Rally Mobile


Mobile, touch, UX

Mobile Hackathon Project

Problem to Solve

The first iOS app built for Rally years ago was under-utilized, hard to use, and never updated. The reviews in the App Store were painful to read. As a hackathon project, a small group of passionate developers at Rally aspired to build a better mobile experience for Rally customers. Time and again, our customers have told us they want access to their data in Rally from anywhere, not just while at their desk. Developers who use Rally also dislike interrupting their flow while coding to enter the status of their work or to look up the acceptance criteria of a task they are working on.

Constraints

The developers hacking on the project wanted to learn the React framework. In a hackathon context, innovation is explored for a specific timebox (usually 1-2 weeks), resulting a proof of concept that Product Management may choose to invest in further. Only features that could be developed in this timeframe were considered, and a responsive approach was the only practical choice given the short-term investment.

Approach

A quick study of our usage metrics indicated that only 1% of traffic came from mobile devices. We crafted a survey to find out why. The results revealed that three key personas (developers, product owners, and scrum masters) would use a mobile version of Rally daily if it provided an easier way to update and view tasks and stories, view team progress, and create new stories, in that order of importance. They would use the app while multi-tasking, commuting, and while at home.

A handful of developers, a product owner, and myself got in a room and sketched out some ideas on paper and whiteboard. We decided to build a separate, mobile site optimized for smart phones while responsively supporting tablets as well. Touch interactions and gestures, as well as a progressive reveal of information would be critical. Lastly, we decided that the interface should more closely follow Android UI design patterns than Apple iOS, as developers primarily use Android devices.

Developers are primarily interested in quickly finding and updating the status of their current work in progress. They most frequently change a task or story to completed, indicate if they are blocked, or find a new story or task to start next. Product Owners and Scrum masters have more of a team focus, and want to know how the iteration is going, is anyone blocked, and create new stories quickly.

The key actions by persona are diagrammed in the task flow below:

mobile.taskflow

Next, I determined the basic UI design patterns that would be used, including lists, cards, forms, and a swipeable kanban board. The order of the screens was mapped into a screen flow, hinting at the UI and navigation that would be rendered on each screen. A hub and spoke model was selected, provided that the menu and search was easily accessible from any screen without requiring too much backwards navigation.

mobile.screenflow

The best way to validate interaction and design decisions for mobile is to build a working prototype. The developers were already hard at work coding based on the flow and wireframes I shared. Given our condensed timeframe for both design and development, we made a lot of decisions as the code was built through rapid iterations. Additionally, I built a prototype in framer.js to test my assumptions with users and to feel the screen transitions on both phones and tablets. Below is a video rendering of the prototype mirrored on a mobile phone.

Wireframes were then designed and shared with the team to show the layout and content hierarchy of each screen. Wireframes for phone and tablet were created side by side to compare how the content reflowed for different display widths. This would help determine the breakpoints needed based on the most effective way to display the content for each device type.

Learnings

We released the mobile hackathon project to early adopting beta customers through Rally Labs, and are currently gathering feedback on usage. The biggest learning for me personally was that the push notifications we had envisioned would be best delivered through native apps. The trade-off of building code for multiple devices using breakpoints had two predictable consequences: the app was less sticky and more difficult to access via a mobile browser instead of an app icon; and customers had to sign in every time they came to the mobile site instead of the seamless authentication provided by a native app.

Credits

Many thanks to Matt Parrish who led the numerous developers through several hackathons to complete this project.