Introducing design to engineering focused culture: an building-upon approach

Challenge:

I would like to introduce methods of design in a team (design here referring to making decisions about having functions and how they are exposed to the user).

Currently, decisions are probably well thought out, but rarely user tested. Assumptions about the users play a large role in planning, but these assumptions exist mainly in peoples heads and are thus hard to share and hard to discuss.

Ideas for an approach:

  • No genius-from-outside: I don’t want to give the impression, that the current approach is “wrong”; rather I want to say, that other “designerly” approaches can build upon existing practices (thinking changes through, considering assumptions about users).
  • shared external representations: I would like to introduce tools like scenarios, personas and user journeys, since they can be jointly referred to and updated (in contrast to just-in-ones-head assumptions); I also want to highlight that work for everyone might be more satisfying when we know that we work in the same direction based on shared, partly, external assumptions (again, making the tools not just a “design” but a “team” thing)
  • Sharing the resources: Currently a bit of an open thing to me. I consider using a Wiki (since it should be easily accessible AND changeable), but I am open for any suggestions.

My questions to you

  • What do you think about the approach? Did you try similar ones and if yes, how did it work for you?
  • Sharing resources like scenarios: Which kind of platform would you use?
2 Likes

Scenarios, personas and user journey might seem like they are a step in addition, that doesn’t provide much benefit.

To be honest what you are describing is very generic, so I’m not really sure what your plan and purpose is, regarding the things the engineering team would learn.

In my team, the only things that worked in terms of design, were practical guides. For example, each dev did his own layout when it came to simple things like forms. So in order to assure the consistency I’m made the form standard and presented to the devs. In terms of consistency I also have a list of the words to be used across labels, like when to create/add, save/update, etc.

When a dev made a design decision that was not optimal, I usually try to explain some rationale in the issue. Improvements are always nice and if justified they usually are getting iterated (like alignment in case of LTR layouts, etc.)

Anyway, it’s not really clear what you want to achieve and what you are referring when you say “design” :slight_smile: , but the best advice is to start with a feature you are working on. I am not sure if “from-the-start” approaches would work (depends if that time is allocated or not in the roadmap and depends also on the team).

I’m curious what you will do :slight_smile: so keep us posted :slight_smile: