Use your widget sidebars in the admin Design tab to change this little blurb here. Add the text widget to the Blurb Sidebar!

(December 2008) Product Potluck

Posted: December 11th, 2008 | Author: | Filed under: Events | No Comments »

Thursday December 18, 2008
5:30 to 7:00 pm
Accelerator Centre
Meeting Room #2
295 Hagey Blvd., Waterloo
[Map]

‘Tis the season to share the joy — and even (gasp!) the grief

Join us on December 18 for a potluck with a twist: instead of food, we’re asking you to bring a product. Make it a product that you either love or hate, because we’ll be sharing stories with each other about these products — and the juicier the story, the better!

A few guidelines and tips:

  • You’ll have a few moments to introduce your product to everyone and describe what you love or hate about it.
  • Be prepared to provide a few words or short phrases that describe your experience in using the product. We’ll collect these words throughout the evening and produce a Wordle tag cloud to illustrate the themes that emerged in our potluck.
  • If the product you want to share isn’t something you can physically bring to the event (like an airplane, or a printing press, or a website), then bring something that illustrates the product. If you’d like to share software or a website, consider printing a screenshot. Alternatively, a laptop, projector, and Internet connection will be available.

A potluck without food? Well, hopefully not.

We’re aiming to make this a fun and informal event. Nothing loosens up a crowd like tasty treats, so feel welcome to inject a bit of traditional potluck into this event by bringing along a food item to share. Now, to be clear, food contributions are not required! Please don’t hesitate to join us if you’re unable to bring anything edible. Everyone understands this could be a challenge, given that we’re meeting at the end of the work day. But if you are able to bring something… well, can you imagine a better way to make new friends? 🙂

RSVPs requested

If you’re hoping to join us, please send an RSVP to Wanda Eby at Communitech. This helps us to better anticipate turnout and plan accordingly.


4 tensions between Agile development methods and User Experience Design

Posted: December 11th, 2008 | Author: | Filed under: Events | Tags: , , | No Comments »

In last month’s workshop on Agility and User Experience, Declan Whelan identified four tensions that teams may struggle with when integrating agile and UX. The crowd split into groups to discuss these tensions and explore some ideas for managing them.

Many thanks to @ericamhc for taking the following notes from each group’s brief presentation — and for sharing them with everyone here.

Tension 1: Advocating for users vs. stakeholders.

First recognize that stakeholders = users. Each are important and must be satisfied to achieve business success.

Investigate and express people’s assumptions about business goals and user goals. Connections will be clearer when both of these elements are understood well.

Explicitly connect user needs to business goals. Avoid advocating for user needs that don’t serve business goals, because they won’t be considered valuable. This doesn’t mean that “usability” should be sacrificed: it means that we need to express the value of improved usability in terms of business goals.

Consider employing user stories (and other methods such as personas) to represent users as “real people”. While you need not formalize these tools, you can sketch them up to help the team connect product and feature ideas back to the needs of users.

Encourage stakeholders to observe usability tests. This brings to life how important usability is to customer satisfaction — and ultimately to metrics such as return on investment.

Tension 2: Balancing technology vs. usability

Take inspiration from popular and effective interfaces that demonstrate strong technology and usability. Our example was Google Maps: while your interface need not mirror these examples directly, they can provide ideas and concepts of what works well and what can be improved upon.

Make key functions simple, especially when constraints of budget and time exist. Focus on the most important and most often-used tasks to ensure they are as simple as possible.

Make interface methods transparent and instinctive. Strive to reduce cognitive load by understanding how people think. Resources: Don Norman’s The Design of Everyday Things and Steve Krug’s Don’t Make Me Think.

Encourage developers to observe usability tests. This can be a valuable feedback loop in the agile process. Usability tests are excellent for highlighting the impact of interface design issues.

Tension 3: Designing up front vs. just in time.

When considering whether to produce documentation at the beginning of a project or just-in-time as you go, consider drafting high-level mock-ups broken into smaller components. Components should be easy to edit and update in response to changing priorities and lessons learned. Take advantage of existing frameworks or tools, even low-fidelity choices such as whiteboards and magnetic interface elements.

Keep teams in physical proximity so discussions are easily joined by other members. This encourages frequent communication and collaboration, which is essential when up-front deliverables aren’t provided. Consider using Skype or other web meeting tools in case you cannot physically be close.

Try building low fidelity mock-ups and prototypes. Consider what tools will meet your needs in the simplest and quickest ways. Paper prototypes and quickly-sketched personas can be very effective, even if they’re never formalized as artifacts. Consider whiteboard sketches, Post-Its, JavaScript frameworks… whatever you think will work. Some people feel that wireframing tools such as Visio may be too detailed and not creative enough for exploring exciting new interface ideas, so don’t let your tools restrict you.

Tension 4: Specifying what to build vs. how to build it.

Keep the vision of what you’re building in mind: focus on the Cathedral, not the bricks. Define the “what” at a high level before deciding upon details of “how” (technologies, designs, etc.). If possible, complete the vision for your Cathedral before the Agile development process begins.

Open communications right from the beginning and make an effort to keep those communications open. Camaraderie is key. Team-building exercises can be instrumental in helping members to communicate, whether they’re designers or developers.

Consider use cases, user stories, and other very lightweight deliverables. However, spending time on them too early or making them specific in terms of tasks can prevent team members from learning as they go throughout the process. These must not restrict you or take up too much time. Jeff Patton suggests a tool called story maps, which can help teams keep their sights on the bigger picture even as they get busy with bringing the details to life.