One thing I never was really good about doing with system design was getting it out in front of actual users to test things as soon as possible, and the companies I work for often overdesign on the front end before getting it in front of users.

I recently was brought over to help on a project in a different department at work, and that project is now in UAT testing after about 2 years of design and development, and they're in the middle of redesigning a bunch of things right now, because the users finally got to sit in front of it and basically said, "Thanks, I hate it."

Like with board game design, you don't usually need to make things polished and good, just get something really basic made so you can show it to other people.

I always knew that was important before, but getting into the habit of doing it with board game design (and watching many things that I come up with and think are brilliant just bomb when getting in front of users) really hammered home that I can't always trust my instincts, especially since the software I'm making is really not for my use (I never use the enterprise software I'm working on right now, except to fix things), whereas some games I design I really do enjoy playing them myself as well.

Another thing with feedback is the concept of 'If multiple people are complaining about something, they're pretty much always right that it sucks. They're also almost always wrong about whatever idea they suggest on how to fix it.' Or basically 'The feeling is right, their solution is wrong.'

Many times I have designed a game just to see it crash and burn when it gets in front of other players (and other designers). They'll tell me they didn't like something and make suggestions on how to fix it, and often my brain will go 'yeah, but that kind of violates the core idea' or 'i'll try it' and you try it and it breaks further. But they're right that it's not fun, or that it gets too hard, or that it feels like they're not making interesting choices, or whatever. And you take all that feedback, you reflect on it, and often will come up with a better solution that addresses their concerns but is also more elegant and doesn't violate some principle of the design.

The same can be true with users of a software system. They can be right that something feels wrong, but there is a good chance the solution they suggest won't work for some reason. Either it technically can't be done, or it's clunky, or it'll violate some business requirements, or maybe it's an 'ok' solution but there's a better one that you can find if you think about it.

Another thing is that game designers can be very valuable to give feedback on the design, and can really point out some major issues with a design, but you have to take their feedback with a grain of salt, because they're not your target audience, and they also have their own particular design preferences and most of their suggestions will reflect that (I do it too, and have seen myself do it). If you incorporate too much of their feedback into the game, it will probably take the game into a very different direction and might not fit your audience anymore (one big thing is game designers tend to be big game players, and especially like more strategic games, so you have to be careful getting their feedback for casual games, that have a lot of luck in them. They'll complain about how much luck is in the game, and make suggestions to remove that luck, and if you did too much of that your game is no longer a light family or kids game anymore).

How that applies to system design is that other engineers probably have very useful feedback to give for your system, especially pointing out structural issues, but they are a lot more technically savvy, and their suggestions will probably lead to a more confusing and complicated (but more powerful) product that might not appeal to a mass audience because it's just too much going on, and a simple design would appeal to them more.

I'm sure I could probably sit down and come up with more. Maybe I should write a short Kindle book about it :).

I just realized I kind of wrote this backwards, i.e. things learned in board games applied to system design, but I think I first saw these ideas in software, and got to apply them more with the faster iteration process of board game design.