Designing as a Team A Collaborative Approach to Web Development

1. Designing as a TeamA Collaborative Approach to Web Development Jeffrey Veenjeff@adaptivepath.com

2. The Project: FirstChurchOfIowa.org • The congregation has formed a Web Committee to expand their online efforts. They’ve contacted you to develop the site and applications for them. • Suggested the following features for an intranet: • Calendar of events (view/add/edit) • Sermon database tool • Congregation Directory • Conference Room Reservation System

3. What is it, exactly, that we are building? • Do some discovery and gather assumptions • Talk to some users • Analyze what they said • Use that for your site’s structure • Sketch out interface ideas quickly as a team • Do a quick usability test

4. The “Discovery” Process • No matter how good your solution is, if it doesn’t fit within the existing expectations and processes of your organization, it will fail • Remember: A sick body will reject a healthy organ if the body isn’t prepared properly first

5. 10 Roadblocks Discovery Can Help You Avoid • Project gets bogged down in approvals • Your assumptions about the goals of the project are way off base • You discover half-way through that the scope is much greater than you imagined • Feature creep • Disenfranchised people become obstacles • Nobody listens to you…even though you’re supposedly “in charge” • Nobody understands what you’re saying (maybe because you don’t have the same understanding of the project) • Someone important and powerful (e.g., the CEO) hates the final solution a week before launch • Your final solution, though cool, doesn’t solve the original problem • Your proposed solution can’t be implemented

6. Exercise 1: Gathering Assumptions • Get into groups of 4 • Choose Roles: • Engineer/Technical Manager • Design/Creative Director • Editorial/Content Strategy • The Client • Without sharing, sketch the product as quickly as you can: • Front page showing features • Scribble out the top page of each application • You only have 10 minutes. Don’t design! Just draw!

7. So who are these people, your “users”?

8. Remember: You Are Not Your Audience • You do not • see things like they do • know what they know • want what they want • work how they work • This is critical information when designing a product So how do you figure out all of these things?…

9. Yak yak yak yak yak yak yak yak yak yak yak yak kak yak yak yak yak yak yak yak yak yak yak... Yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak... Yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak yak...

11. Ah Ha!

12. Open:- Who? • What?- Where?- When?- Why?- How? Closed:- Is?- Can?- Will?- Do?- Should?- Have? Ask good questions • Focus on experience, not extrapolation • Concentrate on immediate experience • Be nonjudgmental • Make questions open-ended • Avoid binary questions

13. Exercise 3: User Research • Designer: Interview the client • How do you work now? (Sermons, Calendar, Scheduling, Directory) • What challenges do you face? Constraints? Politics? • What is motivating you to do this project? • Others, take careful notes. Get as much detail as you can. • Next do the stickies! • Read through notes, listen for “tasks” • Someone write the task on a note as a verb/noun • “Delete Old Sermon” • “Reserve Room” • Cluster stickies as they make sense.

14. Walls of Stickies

15. Exercise 4: Blue Sky Brainstorming and Prioritizing • Share your sketches. • Talk about why you decided to draw things the way you did. • Talk about what technologies you’d would be needed. • Try to channel your role (design/tech/edit/client) • Make a master list of the features you’ll need to build • Add as many other features as you can now. Be creative! • Prioritize the list • Engineer: 1-5 on technical feasibility • Design: 1-5 on importance to the user • Content: 1-5 on resource feasibility • Client: 1-5 on importance to the organization

16. Now – We Make Stuff! • Gather the team, a projector, a whiteboard, and an afternoon. • Talk through the architecture, throwing boxes and arrows together in Visio (or whatever you like drawing in). • Then explode each box into a page schematic. • YOU ALL NEED TO BE INVOLVED! • This is not “designer stuff” • engineers are responsible for technical feasibility • stakeholders own economic viability • design/architecture maintains user desireability

17. Observe Diagram Feng Shui • A flow should be logical and readable by anyone without explanation • Use principles of good visual design • Include meaningful labels for all lines that need them • Don’t cross lines

18. Go With The Flow(s)… • Use standard symbols • Include a legend explaining the symbols • Include error cases • Follow all pathways to their natural end or clearly mark where your flow connects with another flow See also: Visual Vocabulary, http://www.jjg.net/ia/visvocab

19. So What Does The Page Look Like? Daunting, isn’t it?

20. From Collaborative Design to Prototype • Print schematics as PDF files • Add hyperlinks in Acrobat • Fake the forms if you can • Full screen mode makes it your prototype!

21. Save as “Deliverables” • Documentation becomes “What we learned,” not “What I want you to do.” • No more 50-page specs! • Use as a “layer” of your site when browsing No More Specs!

23. Each Site Has a “Layer” of Documentation