Hi, I’m Brian Dys — a photographer from the inside looking out · a composer entangled in electronic music · a UX designer · a spouse, a parent, & everything in between.
About Snippet
0
Comment
I’ve had the privilege to attend a talk at Camera Cart about branding for photographers.
Heidi Aquende invited me to their studio’s 6th anniversary. She did not say who were speaking – only the topics. I chose the first one in the morning and it she who’s speaking.
Please read with discrection since these are simply notes from the actual context of the talk. Nevertheless, the gist is in there.
Make a brand around your company
Using your own name as the company – better because of perceived trust that you will protect your name’s reputation.
Brand Perception
- functional/technical
- emotional
Tip #1 – Offer quality work
- be confident with your work
- poor quality can quickly damage your work
- let clients see you only want quality
- it’s not just the service but also the products
- appear quality – be presentable
Tip #2 – Be clear about what you stand for
- unique selling proposition
- what are your values
- what do you promise your customers
- what makes you one in a million
Tip #3 – Stand out, be different
- differentiate and customize
Tip #4 – Be consistent
Tip #5 – Choose your team
- suppliers, employees
- choose who represents you
Tip #6 – Price better
- don’t show price in the website
- discounts and low prices attract price-sensitive clients who might not be for long-term
- price wars ruin industries
- price drops teache people to wait for the sale which is soemtimes bad
Pricing – 4 ways
- big guess
- competitive pricing
- cost pricing
- demand pricing
Tip #7 – Find the right clients
- you can’t please everyone
- it’s not just about demographics anymore
- rich clients are not necessarily your clients
Tip #8 – Give over the top customer service
- under promise, over deliver
- listen to negative feedback
Tip #9 – Nurture relationships
- Pareto principle – 80% of your income comes from 20% loyal customers
- keep evangelizers happy
- reward referrals
- constantly surprise clients
Tip #10 – Think long term
- don’t scrimp on your brand
- prepare for refund
- plan ahead
Here are some guiding principles we’ve adapted along the way in the web design and development industry:
- It’s easier to ask forgiveness than it is to get permission.
- DRY – Don’t Repeat Yourself
- KISS – Keep it simple, stupid
- HMW – How Might We?
- Be open to changes/improvements
- Invent, innovate
- Always set a purpose and goal in implementing design solutions
- Mind the PageSpeed
- Make it work and make it better
If a component is significant enough, it must contain a component name in the form of a heading element (e.g., h1).
But sometimes there’s a big tone discrepancy between the name of the component and what you want to say in the heading. Consider this example:
[html]
<div class="registration-component">
<h1>Welcome! Please register.</h1>
<form>…</form>
</div>
[/html]
Although, the context of a registration component is mentioned both in the class name and in the heading element, it still fails in providing an official name for the component which can be crawled by search engines and read by screenreaders.
The Solution
It would be what we call an accessible name. It is a formal name for the component inside a heading tag. In the existing example, the heading with the brand tone or voice would be a friendly name wherein we can get creative about.
Here’s a better example of that registration component:
[html]
<div class="registration-component">
<h1 class="accessible-name">Registration Component</h1>
<p class="friendly-name">Welcome! Please register.</p>
<form>…</form>
</div>
[/html]
In CSS, we could visually hide the accessible name and always use a friendly name even if they both have the same content (mostly for HTML markup consistency).
In its basic sense, HTML is standalone. It is independent from CSS especially from the perspective of screenreaders and search engine crawlers. This goes to show about the importance of semantics and content structure in the HTML markup.
In this regard, I strongly advocate for the manipulation of the style sheet instead of the manipulation of the HTML markup.
Consider the scenario wherein you, as the front-end designer, have only 3 chances in having control over the HTML markup and on the other hand, an unlimited number of revisions and updates on the visual design aspect of the project.
This indeed is a far-fetched situation – but it definitely will get us creative in setting up the HTML markup or in planning ahead. This scenario encourages us to use semantic names in the class attribute of the HTML markup as opposed to peppering it with presentational class names which are heavily tied up with the style sheet.