Mobile UX with an Agile Team: Lessons Learned


Published on

Presented at the IxDA Toronto Mobile UX event January 16, 2011.

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • - I work as a UX designer for an enterprise software company called OpenText - it's the largest independent software company in Canada, and chances are, you've never heard of it - this is because what we do is pretty boring stuff: software that helps large organizations manage their internal content - when I say content, I mean anything from documents to workflows to social content: blogs, wikis, etc. - and, not surprisingly, there's currently a lot of demand from our customers to make all this content accessible on mobile devices for the last 5 months or so, I've been working on a iOS app for interacting with enterprise content with an Agile development team based here in Toronto speaking of Agile… let’s have a show of hands…
  • If not, here’s a very quick introduction…
  • Agile is a set of methods designed to make software development more - iterative - adaptable - rapid - cooperative - quality-driven
  • Leisa Reichelt had this great talk a few years ago where she compares agile UX to a washing machine What she means by this is that, in an Agile project, there’s no distinct design stage UX design happens throughout the project... as do business requirements definition, development and testing Can this be a good thing? Absolutely. It allows for rapid change of direction, quick delivery, and continuous learning Can this be challenging for UX designers? Definitely!
  • I think this quote from Jeff Gothelf summarizes the challenge of Agile UX nicely. Over the last 5 months, this is the challenge I’ve faced while working on an iPhone/iPad app with an Agile team.
  • Some of the factors that have come into play in this project: New platforms and interaction paradigms for both me, as designer, and for the development team Guidelines and best practices are still emerging (Apple HIG only covers the basics) - Very short development cycles (1 week) - Business stakeholder pressure to deliver a good user experience quickly All in all, it’s been quite a spin!
  • I’m definitely still adapting my practice as a designer to this way of working But here are some lessons I’ve learned along the way
  • Selling the need for up front research and design to Agile development teams can often be a challenge But you need that time at the beginning of a project to do research and come up with a high-level design direction For me, this was especially important, as this was my first design project for iOS For the development team, this can be seen as an opportunity to address potential technical challenges – so-called “spikes” in Agile terms
  • My initial designs covered the top 2 levels of the IA hierarchy of the app. As it turned out, this was overkill – new business requirements came in, and some of these designs were never used What was important was the breadth of the initial set of designs - it helped both me and the development team think of the app at a higher level
  • During the project, I’ve found it useful to vary the level of fidelity of my deliverables depending on: The precision required to communicate design concepts The team's understanding of a particular design element Initially, the team usually required pixel perfect mockups (which I created using the awesome Teehan+Lax Photoshop stencils!) As their understanding of the design direction and iOS conventions has grown, sketches and textual descriptions are often enough But it’s still very important for me to ensure that they know what I’m looking for through continuous communication After all, in Agile methods requirements are often talked about as “the promise of a conversation”.
  • This was one of my early designs for the iPad version of the app. Split view within global tab navigation. Seems like a very standard layout, right? It’s not. iOS actually doesn’t allow a split view to be nested within any other container. This is an example of what I don’t like about designing for iOS – the HIG makes no mention of this – it’s only found in dev documentation. It’s also an example of one of the things I really like about working with an Agile team – quick feedback loops. Within a couple of days of me communicating this design, the development team had run a spike confirming that it was not technically feasible. But I didn’t have a plan B design option, and as a result we had to rethink the global navigation on the iPad version of the app. So this was a lesson learned for me - have a plan B design solution for the aspects of the design for which the team has not yet explored technical feasibility
  • I think this balance has been one of the most biggest challenges for me in this project As an example, in designing the document viewing functionality for this project, I made the assumption that we would be using the native iOS viewer, which allows for continuous scrolling. I designed the interaction based on a document viewer metaphor, without explicit paging. Later on, the team learned that the native viewer would not support all the document types required, and replaced the native viewer by one that rendered documents on a page by page basis. As a result, we replaced the original interaction with one more similar to an e-book app. As a UX designer on an Agile team, I am the keeper of the design vision. But the vision itself needs to evolve to reflect what I and the team learn.
  • Now that this project is coming to an end, my new challenges will be: - Developing a cross-platform UX strategy for multiple devices and OS’s. Implementing this across multiple Agile teams. Wish me luck!
  • First, let’s have a show of hands…
  • Mobile UX with an Agile Team: Lessons Learned

    1. 1. Mobile UX with an Agile team : lessons learned Dmitry Nekrasovski, OpenText UX Design, Ottawa
    2. 2. A bit about me…
    3. 3. Are you familiar with Agile? Is your organization using Agile methods ?
    4. 4. Agile is a set of practices intended to improve the way software is developed
    5. 5. Agile UX has been compared to a washing machine
    6. 6. "Years of training have taught designers to keep the kimono closed until the design is ready to be reviewed. This bought time AND control. Under Agile, designers need to be more open about what they’re designing and why , and they must be ready to show work much earlier than before . This is a tough change for designers to make." - Jeff Gothelf
    7. 7. Mobile UX adds a turbo spin cycle!!!
    8. 8. What I’ve learned (and am still learning…)
    9. 9. Fight for your right to upfront design time
    10. 10. Make initial design deliverables broad, but not too deep
    11. 11. Deliver just enough fidelity then communicate, communicate, communicate
    12. 12. Be prepared to revise assumptions. Sometimes having a plan B is handy.
    13. 13. Balance your design vision with the things you learn along the way
    14. 14. Next challenge: Defining a cross-platform, cross-team UX strategy
    15. 15. Thank you! Dmitry Nekrasovski // //