Add a chapter on participatory design methods in a remote environment

[semioticrobotic]

Distributed teams often need to make collective decisions in an asynchronous way, often across time zones and geographies. What sorts of open practices can facilitate this?

[LauraHilliger]

Ohhh, we've done loads of fun things here and especially @iamjessklein is a master for participatory, async decision making. Check out an old piece about how we narrowed down Greenpeace's audience using Dot Voting, a spectrogram, etc

[semioticrobotic]

Nice! And I realize "asynchronous decision making" is a really broad topic, so I suspect we'll eventually see individual contributions covering various asynchronous decision-making styles, techniques, experiences, etc. (a chapter on using the "dot method" at a distance, etc.). Would love to see this!

[jimmysjolund]

I think my draft on A3 reports (that was part of the visualizing work) also touch on this subject.

[semioticrobotic]

I fully expect that we'll have multiple pieces that touch, in some way, on this theme, so we'll create new issues for the work(s) as their directions become more clear. Also hoping (:pray:) @iamjessklein will consider, too, because previous work looks amazing.

[LauraHilliger]

I edited the title on this one after chatting briefly with @iamjessklein. Focusing on Design decision making narrows the scope.

This might be a great opportunity to promote the Open Design Kit methods that work in a distributed environment? I think Jess will have loads of ideas here - maybe focus on 1, 2 or 3? Depends on how much you have to say about each one!

To save you time, Jess, perhaps repurposing something you've already written? I'd be happy to have a look at things you think would best fit in the ToC

[iamjessklein]

Okay here's an outline for what I'm thinking, please let me know your thoughts @LauraHilliger @semioticrobotic @jimmysjolund

I. Remote design is possible, here's how.
II. Explore the Problem Space
III. Define the problem
a. what does success look like for your project? (tool: design brief)
b. who are you designing for and what's their happy path? (tools: journey map, personas, hypothesis definition)
IV. Make Potential Solutions
a. Pair design, async design - you've got options
b. Explore some ways to collect constructive feedback for designs and prototypes. (tool: feedback session)
V. Validate the selected Solution
a. how do you get to a minimum loveable product? (tools: affinity diagram, spectrogram)
b. how do you test your solution? (tool: usability testing)
VI. Iterate

[LauraHilliger]

WHOA @iamjessklein that's a lot!! That's like a write up of the whole open design kit! Looks great, and if you're feeling short of time, maybe just describe one method for those spots where you've got two or three, and link to the rest (in print versions, we can point to the homepage of the ODK)

[semioticrobotic]

Wow! This is awesome, @iamjessklein. I'm stoked for this. We'd love to be able to include a chapter on this material in the guide. @LauraHilliger and I haven't yet put our heads together to determine a release timeline for version 1.0, but I'm guessing it'll be some time in the next two months or so (targeting fall). Think we can make this work?

[iamjessklein]

I'm shooting to have some version of a first draft this week (knock on wood), so after that's available, let's review and see if we think the scope is realistic for the fall. If not, I can cut the scope and write an abbreviated version of this.

[semioticrobotic]

All music to our ears. Thanks, @iamjessklein!

[semioticrobotic]

Just began the work of onboarding @iamjessklein into the project. Keep an eye open for incoming invitations!

[iamjessklein]

Update: I'm really behind on getting this to you. I'm not sure if I am going to make your timing now.

[LauraHilliger]

Don't worry @iamjessklein – it's summer, we'll keep iterating and include your piece when you have time. I'll keep bugging you until you say: 🛑 I just really want a Jess Klein original in this, I've learned TONS from you ❤️

[semioticrobotic]

Hearty +1 to @LauraHilliger: Our deadlines are much less important than the ultimate goal of including this chapter from you in the book. What's a more comfortable timeline for you? We can work with it.

[tigert]

Ideally the design process is tied to the development cycle, so that the design concepts and prototypes etc are created and "maintained" along the development of code.

A bit like what the Red Hat Open Innovation Labs does with their "mobius loop" on the Open Practice Library site which alternates a "discovery" (design) phase with "delivery" (development) and iterates between those two, and the designers and developers participate in the design phase, which helps since you have understanding of both design and development constraints and practices.

Just like the software development is iterative, and has the principle of "release often, and early", ideally the design process can happen on the same workflow, and when you realize either the design or code needs an update, it can ideally be done on the spot, with all stakeholders available.