These were the two central themes of a roundtable discussion at the reboot of the Agile Austin UX SIG (special interest group) on Friday. The event was held at BancVue and a Charlotte Wise of BancVue mentioned that the original SIG was spearheaded by a Thomas Tucker and held at Mister Tramps. It seems Mr. Tucker has moved to Houston and his child has been hibernating for over a year, but, now, it's back! This was the first of what are to be ongoing monthly meetings on UX. The coordinators are a Nathan Bussiere of Bancvue (pictured at the left) and an Alex Soufi of Hitachi Consulting (pictured at the right). The three individuals I've mentioned and myself comprised half of a group of eight attendees. The other four were Melissa Brown, a recent University of Texas graduate with a background in UX, Brad Friemel of Volusion, Jeff Neria of Famigo, Inc., and an eighth person whose name I failed to record in my notes. Noteworthy things discussed:
- Many desire an MVP (minimum viable product) but the nebulous definition of MVP often does not include user experience. It was argued that "shallow does not equal shitty" and that a product is not viable without the UX experience.
- UX should fall into the Agile cycle. It's about collaboration and working together in a functional group. In waterfall approaches you are making the best decisions possible upfront with the least amount of information leading to a big GANTT (Henry Gantt's timeline/gameplan flow) chart. In Agile, in contrast, instead of trying to start out with "boiling the ocean" one incrementally creates a product. Alex offered: "UX is about building the right thing and Agile is building things right."
- Constant customer feedback is desirable. How do most businesses get feedback? Do the marketing people just speak of how customers have been complaining? Instead, invite customers to sprint reviews. Ask "Does this make sense to you?" and "Would you want this?" etc. Often the inclusion of having customers present in the process is never built in upfront, and the only feedback a team gets from its clientele is in the form of a bug report. You're not really doing Agile if you're just using Rally and running sprints.
- Where does a UX backlog come from when there is only one person on a team doing UX or worse one person doing UX across several teams. Charlotte told a story of a circumstance in which she was the only UX player across several teams and she found an individual in each team who was the most UX-friendly and recruited a person from each team to form the UX Mafia at BancVue and together they met and developed their own backlog and set aside two to four hours each a week to work against the UX Mafia backlog.
- The gentleman sitting at my right whose name I did not record said that user stories are not: "As a designer, I will create a design for the project." An attitude of "I've got to get this done so it's just a backlog thing" was lacking in his opinion. He said the Agile process makes each step smaller and cheaper and he takes the time to spell out interface requirements in stories. Charlotte will denote fonts and font sizes as they should be in CSS to alleviate ambiguity.
- Jeff wondered if the learning should be happening as the product is being built or if it is better to build prototypes in advance of the product. Jeff has tried to learn upfront with prototypes and mockups.
- Alex told a story of a circumstance in which his team replaced a failing consulting team (which had delivered nothing) at a point at which only a third of the allocated budget was yet remaining. In the pinch, Alex's team decided to only strive to build a prototype. Low fidelity wireframes were provided (quickly) in lieu of more costly high fidelity mockups and the client liked seeing the prototype first. The prototype was something that could furthermore be used (built on top of) in the actual development.
- Axure and InVision were prototyping tools mentioned by the guy on my right (who later also namedropped Basecamp for project management, saying that he had tried it and Trello and Jira and Rally and Google Documents and that nothing was the be-all tool). With Axure one may change the fidelity of wireframes quickly. You can get Axure wireframes in front of people quickly and see how they use it and see if something works. InVision is for mock up comps for flow. Axure is better for more dynamic actions.
- Alex mentioned that his project got bogged down when stakeholders saw things a couple of pixels off and hence it became best to switch to low fidelity wireframe mockups. The guy at my right spoke to how he dealt with the same challenge. He suggested that often clients will want to see the jazzy eye candy upfront and thus he would start out ironing out just a precious few flashy full detailed designs allowing the clients to relax about the look and feel upfront. He suggested that the clientele he interacts with seem to need this in the beginning and once they breathe a sigh of relief the development can fall over to being done speedier with low fidelity wireframes.
- Alex mentioned that when he presented to seventy people that he witnessed a bunch of corporate politics and cutthroat infighting. If the revenue for a department affects a division head's bonus, the division head may ask for a link to his department at the home page of the thing being developed. Alex eventually set a rule in which one had to show up to a demo and provide feedback for the demo within 24 hours or else one lost one's opportunity to provide feedback.
- It might be smart to work on numerous related projects in parallel instead of doing them sequentially.
- Sometimes when one starts to design one may just stare at one's monitor for an hour or three hours and not know where to start. That's normal.
- Don't let prototyping take disproportionate time. You'll know when things are going wrong and it's taking too long. It is supposed to be quick. Keep prototyping a part of the Agile cycle.
- Axure makes HTML functionality that one may click about in. When attempting to emulate a native mobile application in an Axure design there is going to be noticeable kluginess.
- Prototyping should uncover challenges ahead of time. An example: How will the ability to tweak options for products fit into a shopping cart?
- There really should be a sprint zero in an Agile process and during this time a product owner should be busy doing user research. Unfortunately sprint zero tends to just be a time when the LAN and local environment is set up or when, more unfortunately, the designer is put in the tough situation of crafting the whole of the design for all sprints to come!
No comments:
Post a Comment