cyber_roach

1способ
Делается макет волн в SVG, например в InkScape (т.к. там есть редактор текстового кода (координат) для SVG)
В WPF делается базовая разметка в левую часть ( где волны и пр) ставится Grid внутрь которого накидываете элементы Path. в свойство DATA которых прописываете поочередно код каждой "Волны" и пр элементов из SVG. (копируете из редактора кода SVG), далее задаете цвета, прозрачности и пр
Предварительно в InkScape каждый элемент нужно вписать в прямоугольник который будет тех же пропорций что и в WPF, чтобы не мучатся с отступами в WPF (Просто создаются 2 точки по диагонали и объединяются с каждым элементом (чтобы у всех элементов было одинаковое начало координат)

Свойство Data принимает класс Geometry(StreamGeometry) , который по внутренностям = SVG элементу по факту.

2й способ (не рекомендую)
Сделать все как в 1м только вместо Grid использовать Canvas (тогда не нужно вписывать все элементы в прямоугольник в InkScape, т.к. с этим могут возникнуть сложности)
Минус способа - если захотите менять пропорции изображения (зумм) придется пихать Canvas во ViewBox, а данный элемент слишком малопроизводителен и часто дает не качественный рендер.
3й способ
Найдите в сети WPF контрол, который может прямо SVG отобразить.
Минусом 3го способа является то, что например в 1м и 2м мы можем анимировать волны и делать реакции на мышь/тач без всяких проблем, в 3м чисто статика.

1) на выходе лучше просить исходник figma
там не будет проблем самому что-то сохранить в любом нужном формате
Как адаптировать дизайн под смартфоны?
- Заказывайте сразу с интеграцией дизайна в ПО, если нет опыта интеграции дизайна, то скорее всего у вас получится довольно плохо. Если все же хотите делать все сами - заказывайте максимально простой дизайн основанный полностью на Guidlines iOS
2) От каких цен можно будет отталкиваться?
Все слишком индивидуально и зависит как от объема работ, так и от скилов дизайнера. Я, например, не берусь меньше чем за $1000 на простые проекты.
Если не знаете как оценивать работу специалиста - не оценивайте. Просто опишите проект - оформите заказ на фриланс, Фрилансеры сами скажут сколько это будет стоить. Это на самом деле даже более правильно.

Потому что в темплейте элемента списка ListBoxItem базово стоит TextBlock,
а он, естественно, не умет рисовать битмапы.
Просто сформируйте свой дата-темплейт для элемента списка.
Ну и как бы, первый же запрос в гугл дает десяток решений:
https://stackoverflow.com/questions/2081900/wpf-ad...
https://ru.stackoverflow.com/questions/487722/Изоб...

То что вы делаете - плохая практика, вы полностью убьете виртуализацию и это месиво из тяжелых контролов друг в друге будет тормозить, если данных много.
Простое правило - 2 датагрида на вьюху - предел.(в т.ч. и по юзабилити)
Все же RowDetails немного для другого предназначен, вывести какую-то строчку поясняющего текста, описание, статусы, не более.
Не совсем понятно что именно вы хотите, но вроде бы вот решение вашей задачи:
https://docs.microsoft.com/ru-ru/dotnet/framework/...

Если хотите коллекцию в коллекции и раскрывать по клику,
Возьмите какой-нибудь более продвинутрый грид с группировкой.
Или вот руководство как это сделать на стандартных элементах
https://docs.microsoft.com/ru-ru/dotnet/framework/...

За рамку стандартных окон отвечает ОС, а не WPF,
но её можно изменить или убрать, читайте тут:
https://docs.microsoft.com/ru-ru/dotnet/api/system...

Под какую платформу?
Это собственно главный вопрос. Выбор языка сегодня вторичен.
Кроссплатформенность сегодня это миф, так или иначе вы будете либо идти на компромиссы (часто жестко), или мучатся с каждой ОС по отдельности по факту используя пару десятков общих классов которые вам и в обычном (не кроссплатформенном режиме) никто не мешает собрать под все платформы в отдельный ресурс с той же скоростью.
Выбор платформы
* Если windows ничего не мешает использовать UWP / WPF
* MFC -вы серьезно хотите писать ПО на библиотеках 92го года? да они поддерживаются, но новое что-то писать на этом разве что ради фана, либо что-то специфичное под старые win системы.
* CEF - не сталкивался, но думаю мало что хорошего в идее использовать браузерный GUI и плюсы. (если не для браузера пишите)
* QT, сложный вопрос, есть его ярые поклонники не признающие ничего кроме, но я к нему нейтрален, считаю его устаревшим, хотя для встравиваемых систем и под линукс - да, т.к. практически нет альтернатив часто. Под эти платформы я бы выбрал qt только потому что на нее много информации в интернетах и сообщество имеется.
* под мобильные платформы... все довольно сложно, решений вроде как есть, но я бы сегодня использовал для GUI что-то другое(Например Flutter), а c++ для отдельных модулей ибо - замучаетесь отлаживать.
* Если GUI хочется сложный и необычный/игровой да еще и кроссплатформенно Я бы использовал необычное сочетание UnrealEngine + NoesisGUI, где Unreal решит все проблемы с платформами и производительностью Noesis с разметкой UI. Но придется пожертвовать почти всеми системными функциями на каждый чих делая кастомное решение.

Важные моменты
- Графическая библиотека должна использовать железо на максимум.
т.е. без апаратного ускорения и отрисовкой видеокартой можно выбрасывать все ваши красивости на помойку.
Наверное часто замечали что над GUI постарались, но забыли про производительность.
Если под win попробуйте UWP, он супершустр, если честно быстрее и качественнее него в отрисовке GUI ничего не встречал. Съедает любую сложность GUI при верном подходе для любого устройства ввода-вывода (клавитура/мышь, тач на 20 касаний, сенсорные перья, VR…) Какой-нибудь QT возможности даже и не снятся, хотя вторая много старше.
К сожалению платформа не популярна. Есть небольшая, но вероятность, что сдохнет, т.к. windows маркет не развился. Хотя недавно добавили возможность писать ПО и для обычного десктопа минуя распространение через магазин, но пока все сырое. ну и так же MS выкладывает все потихоньку в openSource это радует.
Хотите стабильности от жизни - берите QT, лет 10 еще точно актуальна будет. Хотите простоты и скорости разработки, UI посовременнее и посложнее - что-то из нового.

- Второй момент, после производительности. Графическая библиотека сегодня - это совместимость с "современным дизайном" .
Что я имею ввиду: когда дизайнер вам дает исходник в Figma/Sketch, иконки в SVG видео в h264 и пр. и вам нужно рассмотреть использование этого всего на устройствах 96-300 dpi где все будет адаптивно и подстраиватся под размеры и ориентацию экрана. Вы не должны испытывать боль заднего прохода. Берете и делаете, т.к. у вас есть для этого инструменты.
Наверное видели супермелкоту в windows программах когда DPI экрана под 300, это как раз MFC, QT и подобные
Про линукс на FullHD планшете 8" это отдельная большая тема беседы. Хотя вроде как в последних сборках имеется поддержка hiDPI устройств.
Тоже самое под мобильные платформы. из-за разнородицы dpi я как раз и рекомендовал использовать что-то вроде Flutter, т.к. он создан для таких устройств, в отличии от многих библиотек допиленных, созданных еще для PC в лохматые года, через костыли говна и палки пытающихся как-то с грехом пополам отрисовать несвойственную ей среду, по пути теряя все преимущества производительности плюсов.
Хотя, справедливости ради, я видел С++ решения которые на мобилках летают суперски, но это уже вопрос профессионализма, крутой барабанщик и на кастрюлях сыграет много лучше новичка, но учится лучше на хорошем и заточенном инструменте.

- Дать немного воздуха, т.к. списки - просто белый фон с текстом, без него получается визуально прижато к краю сильно из-за того что элементы как правило довольно большие по высоте (под сенсор)

- Такой подход решает проблемы со скруглениями элементов на интерактиве если сам попап списка закруглен, поэтому иногда отступают чтобы не мучатся с версткой.