Interviewing: Round one

[deathbearbrown]

For the first milestone the users we are focusing on are Bocoupers. The term is broad and covers people with the following roles:

• staffing
• sales
• engineering
• data visualization
• project management

I'm going to interview one person from each of these roles to get a sense of what assets they need to understand what design is and how it relates to their role at Bocoup.

MONDAY (may 16th) Interviews:

• Brian (staffing/pm/sales)
• Yannick (data vis)
• Lorin (pm)

Tuesday Interview: Irene Bmac

Questions:

• Do you think design is important for project success?
• What's you're relation to design/ux at bocoup? Have you ever done it? Worked with a UX person?
• How do you currently [do/sell/staff/manage/work with] design?
  • successful examples (why?)
  • failures (why?)
• What would you like to know more about re:design as a deliverable?

[deathbearbrown]

Interview 1: PM/Account Manager

Q: What is a successful design project to you?

• our people delivered something they are proud of
• the client is happy and feel that they got more than their money's worth
• the users of the application are happy and benefit from our work

Q: Pretend I have no idea who you are and tell me what you're relationship is to design work here at bocoup.

• I am a PM on a large design project
• As well as managing I am active in design workshops we give to our clients

Q: Can you give me an example of failure and success of our design process at Bocoup? Failure:

• communication issues with the clients
  • issues around our design vocabulary and assumptions that definitions line up the same.
  • client's idea of wireframes were very finished clean mock ups
  • our wireframes are unfinished and are used as tools for discussion
• for our process we need constant feedback from the client and we need to set that expectation up front
• explain what our assets are

Success:

• once communication improved the client sees a lot of value in our design assets
• our design assets are great and very useful, only the communication was the issue

Q: If you were looking up documentation about our assets to explain them to a client, what would you want to see there?

• we had a lot of success running workshops with the client. You can tell them what a journey map is, but having them make one was better. They saw the value. It was easier to keep their attention when they are trapped in a meeting
  • Q: so we should have instructions on how to run workshops for different assets?
  • yes

Q: Super broad general, what can we be doing better question. Like, how about handoff and storage and all that stuff

• one issue we have is a lot of our discussions happen in invision and they can't be archived in a random cloud service.
• explaining to a client that "final assets" isn't a thing we do. Nothing is every final.
  • Q: Like finalcomp.psd, newfinalcomp.psd, newnewfinalFinalcomp.psd?
  • yeah everything is a work in progress

Q: what about storing the history of decisions? Any ideas on that?

• we do a lot of meetings. I send out an agenda before and meeting notes after, but we don't have a solution for storing all of that somewhere.

QUESTIONS FOR THE TEAM: What about when people only like to communicate through email, slack, irc etc, how do we keep the history of decisions and where do we keep them?? in a wiki?? What if the client isn't on github??

[deathbearbrown]

Interview 2: A DataVis engineer (my notes were real bad for this one, are these even sentences??! )

Q: What do you do at bocoup?

• Data visualization design and engineering
• Types of design I do:
  • create data visualization software that meets client's goals.
  • software design, how we shape our code

Q: Can you describe a successful design project here?

• our current project is pretty successful
• formal design phase (first 2 months)
  • explained to client that we needed more domain knowledge and need to talk to users Q: What kind of design tools have you used?
• we have done user interviews and created personas
• the client was present during interviews, it was a little hard to stop them from answering questions with their own biases. They did ask some questions we didn't think to ask.
• personas were more for us internally
• used google docs to share notes from interviews. One person was the note taker, one person the interviewer
  • created textual journey maps that were short narratives
  • lots of sketches with mockups
  • site map with sketchy thumbnail - this was very useful with the client

Q: Did you have to justify design work to the client at all?

• we would send them a table with the tools we wanted to use that linked to descriptions from 18f. We also wrote why the exercise was important
• sometimes how involved the client was had to do with reading when more or less collaboration was needed
  • the client had periodical demos and expected more polished work for those
  • the client was new to a lot of the UX principles we used

Q: What kinds of things do you think would be useful to document in a kit like we are making? what tools have been helpful so far?

• datavis team is kind of doing their own stuff with visualizations based on user data talk that Irene did
• seeing examples of how something is done
• what kinds of tools and apps people use

Q: How are you delivering assets?

• email centric client, emailing pdfs
• sometimes painful to get feedback
• lots of calls
• invision is better for async feedback
• keeping invision at the latest version at all times helps

Final thoughts: Yannick is thinking about a lighting talk for design that is not user centric

[deathbearbrown]

Interview 3: A PM

NOTE-- this was less of an interview and more brainstorming about PM stuff with Lorin. She hasn't had a design centric project here other than Lyra which was pretty chill.

Q: What is design? I think it's a person who puts together the concept of what an app should look like, but doesn't write the code. From Wilto she hears "I'm a designer, not a developer."
From Susan she hears "I'm not a designer, I'm a developer." So this is based on that.

[note here I just started asking some client relation questions I was curious about] Q: How do you get clients who aren't responding to you to pay attention?

• slack is great because it interupts them
• norming in the beginning should happen with clients, you should get their preferred method of communication
  • example: we had a client who said that big decisions could only be made over email so there was always a paper trail.
• understanding the client's organizational structure
  • who else can I ask if my primary contact is non responsive?
• be clear about consequences. I am blocked, I can't move forward. You're wasting your money if I'm blocked.

Q: Any ideas around keeping documentation about decisions during the lifecycle of the project?

• meetings, have a note taker, have action items emailed after the meeting with due dates. Track if the action items are done

From talking to Lorin I wonder if we need to communicate what Design is every time someone onboards??

[deathbearbrown]

Interview 4: Open Web Engineer

Q: What do you do? I am an OWE. I do consulting. I help clients and their devs learn more about javascript, testing and writing better software. I also help clients achieve their goals for their products. With regards to design, I usually implement what I get from comps or wireframes into prototypes or web applications.

Q: Can you describe some successful design projects and some unsuccessful ones?

Successful:

• worked early on with a design team, giving them constant feedback and helping them make decisions for mobile and different interfaces
• made prototypes for designers, quick iteration on feedback
• had design partner spend a week of straight meetings for handoff and no asset creation going over design doc. Doc was less than 100 pages, but more than 50. Meetings had a presentation about the doc and answered questions. When the designer left we knew exactly what the client needed and why. When the client made new decisions that went against the design doc, we were able to push back knowledgeably.

Unsuccessful:

• scope for design is hard. We tend to focus on what is possible instead of what is possible in specific time constraints
• one project had no clear personas, so we were building for 2 possible users, but not committing to either. This project had no design.

Q: Communication about design and our processes? How we doing?

• Creative Confidence (book) - talks about business value of design. Justifying design to a CEO
• sometimes we don't take enough time explaining why design processes work
• Being sneaky - some clients want to make decisions for their users and want full control.
  • we need to explain why they aren't the user
  • onboarding new people to the design process and why we do it, sometimes bores people who have always been there and already know it's important
• Pre-existing rituals and process don't account for design and hurt the project. Don't make assumptions that they will work for a design team. Communicate PM needs early.

Q: Asset handoff, what's good?

• the project where we had the handoff from the design team that was a large doc was really great. They spend the last week or two not making new work or artifacts, just perfecting the design doc and discussing it with the client and engineering team.

[deathbearbrown]

Interview 5: A Director (Sales, staffing & datavis)

Q: What do you do?

• Director of Datavis. Support datavis projects, do sales, operational tasks (finance and contracts), department strategy

Q: How do you sell a 'design phase'?

• Found that 'discovery phase' was bad terminology. Clients thought it would cost less or had less value
• 'Research and Prototyping Phase' is easier to sell and show value
  • discover all stakeholders, domains of product, learn about data
  • having a full picture before development means better software and less rebuilding later
  • prototyping means they can touch things sooner and give feedback
  • data discovery phase, ensures the data is good and will be able to do what client wants
  • "Data Driven Design"
  • custom tailor to clients specific needs
  • information design
• "User Design" harder to sell, bucked in with DDD.
• Clients love that they are so important that they need to be researched

Q: What are some successful Design projects? & Unsuccessful ones? Successful:

• projects that have a long design phase up front
  • client was unsure what they wanted
  • spent most of the time getting to a point of productive conversation
  • required a lot of research and decision making
• projects with one person & a lot of prototyping
  • design and dev can go on at the same time
  • client expects a lot of throw away ideas

Unsuccessful:

• Design and development are happening at the same time
  • very stressful
  • harder to collaborate
• No design phase
  • lot of assumptions made
  • client gave delayed feedback
  • client was not in agreement with the direction of the work

ADDITIONAL THINGS THAT CAME UP:

• Knowing skill specialities among design team.
• Not having the proper language in design terms to ask questions or know who can answer questions.
• Knowing who is best to staff for a specific type of design.
• Not knowing all the different types of design that people can specialize in.

[melodykramer]

Do you ever recommend doing these interviews as a group?

[pamela-drouin]

@melodykramer Hi! I recommend doing this kind of interview one on one (or ideally, an interviewer, an interviewee, and a note-taker who can also ask a follow-up question or two). We've moved our content to a website, if you'd like to read more: http://opendesignkit.org/methods/interviews/