Track: Building Sakai
Description: * *If you've ever wondered how project teams decide on what changes to make and how users influence this process, the Stanford User Experience team will share their process, and will encourage others to share their own best practices.
Presenters: Keli Amann, Stanford University
Slides: Visit Slideshare
On Thursday 7/9 I gave a talk called How Users Influence Design and Development. It focused on how we were organized and communicating within a campus and between campuses so as to enable users to have influence on development. During the talk, I showed the structure of our team at Stanford and how we interacted during local development in contrast to 2.x releases.
The talk was meant to solicit examples from other campuses, but since there was no time to discuss, I asked people to draw a flowchart showing how users were connected to development on their campus. Nine people representing seven schools turned in their drawings, ranging from Support, to Instructional Designers, to UX/UI designers from Indiana, Michigan, U of Virginia, Cambridge, UNISA, NYU (pre-production) and Boston University. I promised to share the results -- below are 6 representative drawings, followed by a textual description.
1. Although people may not be describing the whole picture, the following is still interesting.: It's possible that some of these workflows are not entirely accurate because
a. they forgot to draw in arrows--there may be connections that they are aware of, but weren't captured (a user researcher showed herself talking to users but not the UI designer, which is surprising)
b. People at the same school can describe the process differently--they tended to focus on their immediate connections in their drawing. A functional analyst, a UX designer, and a Instructional Designer at one school had very different drawings, possibly because they don't see or didn't explicitly draw out individual roles in the organization they connect with.
2. Campuses structure themselves differently. This depends on size, stage of production, and probably historical attitudes.
a. Sequential - UX as bridge - sometimes UX designer is removed from users by several roles
b. Network--not just a straight line
3. Team members sometimes wear multiple hats. At one school, one person does support, UX/UI Design, and QA, and is the project lead for transition to Sakai.
4. There are various user proxies in instructional, UX (interaction/interface/UI), and support roles -- sometimes one, sometimes multiple. This means that developers are sometimes designing. It also means that developers who seek user insight at other campuses may need to approach people in different roles than they might expect, based on their own local experience.
5. Although it's possible they just forgot to draw this in, only four included external users in their development. When it does happen, users are included in different ways
6. Many campuses don't communicate much with developers at other campuses.Only two schools do, and this is undertaken by either support or instructional technologists. However, since participants were asked only to show how they were connected to *developers* at other campuses, they may be connecting with other schools via other roles.
7. When asked what's working well, what's not, there was a feeling that development was disconnected from users. However, answers on how to solve this varied
For sake of inspiration, here's a compiled list of tools that people use to capture and communicate between roles (no indication of which tools are used to talk to users versus developers, but I've tried to roughly group).
Methods of gathering user data
User Interviews (observations/questioning)
Methods of capturing user data
Methods of communicating design
General communication methods
Meetings (in person, on web, video)
Discussion groups (one explicitly uses tool in Sakai site)