I recently attended a session of the London Agile DiscussionGroup where the focus for the night was UX, what is it, where does it fit in the lifecycle of an agile project? To me it was a very interesting night as I have not worked directly with a UX designer before. I was intrigued to see how others have done it.
I was especially keen to know whether they had been able to work
in a continuous manner (UX developed in the same sprint that it is applied to
the product) as opposed to working sequentially (UX developed in Sprint N, UX
applied to product in Sprint N+1). Going into the night I had seen couple of
ThoughtWorks presentations on Continuous Design.
However because I had never experienced it, I was open to possibilities on both sides of
the debate. At the end of the night I had heard three tales of Continuous UX occurring
in the wild and about 70% of the attendees believed that it will be possible for
them to do Continuous UX in the future.
For me there were three key takeaways from the night:
- Continuous UX is possible.
- The key to Continuous UX is small User Stories.
- UX needs to involve feedback from real users; ideally the feedback should be analytical data. Otherwise it is just guess work and not really UX.
From what I heard most UX is a case of cyclically
incorporating the feedback/data into the on-going design and development work.
There will be some UX Debt accumulate, but you need to keep it low as the cost
of those UX changes can quickly sky rocket. In summary UX like architecture,
needs to be a little bit ahead of the daily sprint work, but not sprints ahead.
One of the real life success stories I heard, was of a small
team (1 UX, 2 developers & 1 QA) building internal system and working on
small User Stories. The UX guy would produce working CSS of the item in half a
day, and work with the team on refining it. They were able to deliver a
continuous flow of changes that incorporated UX. The UX guy building directly into
CSS and not writing down his ideas; was a large part of their success, along
with their small stories that lead to simple UX.
Restaurant Booking Web site scenario
To put our new found knowledge into action, each table of
participants at the meet up, took on the following scenario. As a new project
team, create a web site for a local restaurant that allows them to take bookings
for dinner. Outline the project plan sprint by sprint for the first couple of
sprints. From my memory this is what we came up with as a team.
Sprint 0
- Establish team
- User Story Workshop & Project envisioning
- Establish Infrastructure: hardware, coding standards, continuous integration, etc.
- Deploy a hello world home page that is not published to DNS servers hence is only available to navigate to via entering the IP address.
- Create architecture that allows for AB split testing and analytics capture
- Create Brand Guidelines – style guides, reusable controls such as buttons.
- Conduct Market Research
Sprint 1
- Deploy a publicly accessible holding page that uses the brand guidelines, indicates that a full web site is under construction, shows the address, phone number and e-mail address of the restaurant.
- Conduct AB split testing on some different holding pages.
- Start working on the highest priority User Stories, incorporating UX as we went.
Photo Credit: http://www.flickr.com/photos/murdocke/
No comments:
Post a Comment