Sanches

Ну тут надо уточнить, что дизайн сайтов/приложений не является продуктом. Это услуга.
"Картошка" - это продукт. "Доставка картошки" - это услуга. Вы предоставляете услуги, соответственно ставить вопросы надо исходя из понимая этого.

Бизнес выбирает поставщика услуг по нескольким пунктам:

1. Доступность - важно что бы было легко вас найти.
   
2. Понимание проблем клиента - важно что бы поставщик услуг четко понимал как его деятельность скажется на нашем бизнесе.
   
3. Скорость реакции сотрудников и их вежливость - тут думаю все понятно, если на email отвечают неделями и на от*бись, то такой поставщик услуг не получит заказ.
   

В контексте вашего вопроса речь идёт о "Понимании проблем клиента".
И тут важнее не написать большой список, а выбрать конкретный пункт и давить на него. Объясню:

1. Увеличение продаж - на этот пункт вы влияете очень косвенно (ниже объясню почему). Потребитель больше будет смотреть на цену и скорость доставки, чем на форму кнопочки "Перейти в корзину".
2. Привлечение внимания - это тоже не ваша работа. Привлекают внимание маркетологи. Клиент даст рекламу в директ, и она будет привлекать внимание. Если вы занимаетесь дизайном рекламных баннеров, то тогда можно говорить о привлечении внимания, но в контексте вашей деятельности вы привлечением внимания к продукту/услуге заказчика не занимаетесь.
3. Большая конкурентоспособность/отстройка от конкурентов - это тоже не про вас. Конкурентоспособность никак не соотносится с визуальной составляющей. Вы можете сделать идеальную упаковку для пиццы, но если её везут 3 часа, то никакой конкурентоспособности быть не может.
Отстройка от конкурентов - это тоже не про вас. Немного погуглите про то что такое "отстройка от конкурентов", и поймете это. Отстраиваются на уровне позиционирования и бизнес процессов. Например вы открыли магазин продуктов возле дома. Через пол года рядом открывается пятерочка. Вы начинаете проседать по доходам, потому что пятерка дает лучшую выходную цену для клиента, и тогда вы решаете отстроится от конкурента, убираете весь ассортимент и становитесь магазином "Колбасы от Васи". И расставляете на прилавке 1 вид продукта, но в широком ассортименте, который пятерочка никак не может себе позволить, потому что им не выгодно иметь широкий ассортимент одной товарной позиции. Вот это и есть отстройка.

А теперь к важному. Продавайте "Повышение конверсии". И только это.
Бизнес делает рекламу, тратит на это деньги, и тут появляетесь вы и говорите, мы можем сделать новый дизайн вашего сайта, уменьшить "боль" потребителя от использования, что повысит вашу конверсию на N процентов + увеличит кол-во повторных заказов от существующих клиентов. Повышение конверсии даст большую эффективность вашим рекламным затратам, потому что вы можете потратить 100500 миллионов денег, но если вся реклама будет вести на непродуманный, некрасивый и абсолютно неюзабельный лендинг - ваши деньги вылетят в трубу. Такая постановка вопроса будет очень понятна любому бизнесу.

Так что вывод - переимуйте абстрактный пункт "Увеличение продаж" в более конкретный "Увеличение конверсии", и продавайте его.

Gmail -> вкладка "Промоакции" -> первые 20 сверху от разных адресантов

Возможно, имелось в виду использование семантической сети в качестве движка для хранения данных вашего сайта. В таком случае вы будете хранить данные в виде маркированного графа в формате RDF, поверх коего, возможно, построите онтологию на языке OWL. Чтобы получать из хранилища ту или иную информацию, будете использовать язык запросов SPARQL.

На ум приходит одно мейнстримное решение - монструозный OpenLink Virtuoso, но существует множество других библиотек и инструментов для разных языков и СУБД, их можно поискать.

Познакомиться с технологиями Semantic Web полезно и интересно. Но использование семантического хранилища вместо реляционной или, на крайний случай, нереляционной базы данных в большинстве случаев представляется не очень рациональным. В первую очередь потому, что медленно это. И потом, большая часть данных в реальной жизни имеет табличный характер и прекрасно ложится на реляционную базу; а начав возиться с triplestore, немедленно начинаешь страдать от отсутствия привычных уже реляционных плюшек.

Плюсом семантического хранилища является его гибкость и "разумность", если можно так сказать. Положим, вы строите структуру генеалогического дерева и хотите показывать на сайте, сколько у вас дедушек и бабушек. Тогда вы создаёте в своём графе узлы для себя, своих родителей, родителей их родителей, соединяя их дугами вида "родитель-ребёнок". Сделав это, вы можете написать средствами OWL правило: если C мужского пола и является ребёнком B, а B является ребёнком A, то C - внук А. И так далее.

Теперь вы просто пишете SPARQL-запрос, который возвращает все такие узлы Y, что Y является внуком X. Остальное за вас посчитает движок семантической сети.

Возможно, именно это от вас требовалось - я делал курсовую когда-то на эту тему.

Моё личное мнение состоит в том, что за технологиями Semantic Web будущее, но языки SW являются скорее прослойкой между системами, чем реальными языками для описания и хранения данных. Глупо в RDF-графе хранить большие объёмы хорошо структурированных данных, таблицы для этого подойдут гораздо лучше. А вот связывать разные системы меж собой посредством RDF и обращаться к ним через SPARQL - это интересно.