Skip to end of metadata
Go to start of metadata

Track: Building Sakai

Room:    Aquarium

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

Followup: How 7 campuses organize flow of information from users to developers--variability in roles and structures

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

  •   i. Users talk to lone Support person,Instructional Technologist, or UI designer, who talks to developers
  •   ii. Users talk to Instructional consultants/designers talk to UX designer/ business analyst who talk to developers
  •   iii. Users talk to Instructional consultant who talks to Functional Requirements Committee who talks to UX designer/ business analyst who talks to developers

b. Network--not just a straight line

  •   Designers talk to internal and external users, QA, support
  •   Working group of IT, faculty, instructional tech, libraries talking to users and going to developers (pre-adoption)

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.

  • Instructional designers/ technologists/consultants are common, but are sometimes the only role missing at a school, or are the only role interfacing with users. In a couple of drawings, they are the ones working directly with developers.
  • UX: UX designer is present at 3 schools. In one case, while the UX role interfaces with developers, she also shows users going directly to developers. In another case, two other colleagues from campus in different roles didn't draw her in but probably because they see her as part of the developer group.  In at least 3 cases, either instructional designer or support seems to be working directly with developers. At times, there are multiple UX roles--not just a designer, but a researcher or analyst.
  • Support: This role is almost always present in schools in production, but there is a lot of variability as to whether they are drawn on--4 schools included them in the workflow.

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

  • Instructors talking to instructors at other campuses, and local roles getting information second hand
  • Designers talking directly to external users
  • Support fielding questions from external users outside own campus, and feeding that in

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

  •  UX designers had varied feedback, depending on how their network was structured. One was in an organization where she feels like the development leadership circumvents her and only turn to her for "after-the fact critique and visual polishing). Another was in an organization  has every role represented by a distinct person where she feels like the relationships are good, but still wishes she could have more direct contact with users (see 2a); her colleague said they needed more designers and more time for design. The third was well connected (see 2b), but has concerns that there "may be too many people/roles to consult, especially since we are trying to get broad community involvement."
  • Non UX designers seemed to emphasize connection of other roles to developers, likely because "development" is seen as a monolithic black box. For instance, an end user wants developers to have discussions with end users. A user researcher with wants to make sure support is also included

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 diaries
User Interviews (observations/questioning)
Training workshops

Methods of capturing user data
Context Scenarios

Methods of communicating design
Adobe Fireworks

General communication methods
Meetings (in person, on web, video)
Discussion groups (one explicitly uses tool in Sakai site)
Google Docs
Local JIRA
Community JIRA

  • No labels