Design after familiarising yourself with a platform

Take the time to get to know the platform, web technologies, and end output you’re designing for as each platform has design and functionality related limitations. If you don’t do this first, there’s always the danger that you’re going to design something that is completely wrong for the platform or cannot be coded within a reasonable amount of time. So make sure it’s possible first!

How do I do this? The easiest way to do this is to use the platform and see how it works. Being aware of what scenarios and platforms you’re designing for will help you figure out how big your sandbox is. It also means setting the right expectations for what’s possible with tech. This way, you don’t over promise to your client or product owner only to later say that a key feature you designed can’t be coded.

For example, within WordPress, get to know:

• The content pop workflow in Gutenberg and see what the output is on the frontend
• Widgets
• Custom post types
• Popular plugins like Gravity Forms, FacetWP and FooGallery

For web tech, get familiar with knowing:

• Solid responsive design knowledge from small to 4K screens
• Bootstrap components
• How social sharing works
• How designs will affect website performance

This is by no means an exhaustive list, but it should give you a good idea of what you need to know. Still unsure? Talk to a frontend (FED) and backend (BED) developer for some guidance.

Keep in mind coding effort

It’s very possible that a little bit of design will result in a lot of coding. A typical scenario I’ve encountered is when a designer has designed a seemingly simple feature in a minute, however, it ends up taking much longer to code during FED and BED. The reason for this significantly longer development time is that making designs functional may require more complex backend logic. The danger of not considering coding time and effort is that you’re designing development heavy features that are time-consuming to code which can result in your product development running behind schedule.

Say you’re designing a product sash for products on an ecommerce website. The designer has already designed several product sashes like Sold Out, Popular and On Sale that have backend logic (rules that dictates behaviour) attached so that these sashes will only appear in certain cases. For example, the backend logic for the Sold Out sash means it only appears when the product inventory is 0. Now let’s say that we want to add a new sash for “Popular”. Design and FED-wise, this would probably be pretty fast because there’s already an existing sash template for the designer to modify and existing sashes implemented from which to create a new HTML element in FED. However, the effort to backend code the Popular sash is much higher.

Track time with Toro Timer

Toro helps remote teams stay productive no matter where they are.

Get early access

In order for the BED to code the Popular sash’s backend logic, they first have to know the rules for what constitutes as “Popular”. Different versions will also take different amounts of time. For instance, one possibility is where the product owner wants the Popular sash to show if more than 20 units have been sold within the last two weeks. Alternatively, they may want to be able to manually control what is labelled as “Popular” in which case the admin can tag the product as “Popular”. So depending on these two types of BED logic, there would be a big difference in the time needed to code.

Now, developers generally do not shy away from coding (or at least we hope that they don’t!), but you have to consider how much work you’re creating for them down the line. This is especially important when you have multiple designs and products to juggle and client or colleague expectations to manage. In this light, it might be better for you to give up on this feature (for now) or coming up with a pared down version for the sake of staying on schedule and not overworking your developer.

What should I do? Think about what kind of logic would be needed to execute your design first then consult your client, product owner and friendly neighbourhood developer before proceeding with design. You may find out that what you want to do is not realistic or of low value to the end user. Alternatively, you may find that it’s easy to design, code and has great value! Either way, you’re better informed about the effect of your designs.

Design reusable UI components

It’s important to remember that designs need to be practical, not only in terms of how it will be initially coded but how it will be managed in the long term. In tech terms, this means thinking about designing UI components so they can be reused across the website or app. This adds to the longevity of a design because it can be easily maintained from a backend standpoint while still looking good on the frontend. In order to achieve this you may have to reach a compromise with your design’s aesthetic elements in favour of ease of maintenance.

Let’s explore the consequences of this in an example. You may have chosen to design a website which has varied irregular shapes (think jellybeans and splats). Though this may make for a more visually interesting design, it might become hellish for developers as variations might lead to the writing of bad or unmaintainable code. This is because every unique shape has different margin and padding requirements and the more variations there are, the more low-level coding is required to fine tune them. If the developer is inexperienced, there’s a possibility that the way it’s been coded may not be so readable, elegant or maintainable. This means that if another developer, or even the same one, comes in later, they will have trouble understanding the code and will therefore have more trouble fixing it. More design and coding variations also means that the developer cannot use a blanket fix on them and must spend more time coding a fix for each one. Another problem is that with more code comes more opportunities for older code to break. The end result? Massive headaches.

The last point is that people usually do not end up using all the bells and whistles you designed. Though the website may look fancy after you initially deploy it, your client or whoever ends up doing the content updates and maintenance may not choose to follow suit, or, may even get confused if there are too many options. They may very well end up sticking to one or two elements that they’re comfortable with for content population and forego the other options. All the other stuff you designed and coded will then be wasted effort.

What should I do? Although it is possible to use as many shapes as you like, think about how they’re actually going to be coded and maintained later. One strategy is to design UI components in a way that makes them reusable. Set a fixed number of variations e.g. 4 and stick to those only. The definition of maintainable code is that it’s code that is easy to modify, extend and debug. By designing a custom shape that you can then flip horizontally and vertically to make “new” shapes, you will get the visual variety that you need while still making it easier for the developers to write fixes if ever they break. It’ll also hopefully be simpler for whoever maintains the website in the end.

There you have it folks! Though it’s easy to create aesthetically pleasing designs and features, you have to consider the direct effect design will have on FED and BED and beyond. Remember, design isn’t just about how it looks, it’s also about how it works and what the experience is like for others that you’re working with. Talk to your developers often to discover limitations and peek into what it’ll be like to maintain the design in the future so that you design with development in mind.

The post Designing with Development in Mind appeared first on Stampede: the strategic design & technology company.

Every year, we send three team members to handle the work onsite during the regatta, however, it’s only one of three phases in our work on the RLIR website’s year-long cycle. In this post, we’ll let you peek behind the sails to see what really goes on throughout the year leading up to, during and after regatta week to ensure smooth sailing and timely web updates at the event.

A crash course in the Royal Langkawi International Regatta

Before we start talking about what we do at RLIR, it’s important to get the lay of the land or, uh, sea before diving into deeper waters. Here’s a quick look at what happens at the regatta this week.

What, when and where is the Regatta?

The RLIR is an annual sailing regatta, or series of sailboat races, hosted and run by the Royal Langkawi Yacht Club that takes place along the coast and surrounding islands of Langkawi, Malaysia. Drawing many local and international yachting teams, the regatta is an awesome display of sailing prowess and teamwork. The event takes place in early January (this year, from the 6th until the 11th) when the weather is characterised by clear blue skies, strong winds and scorching heat; the sunshine alone guarantees an epic sunburn for those who didn’t get the sunblock memo.

Regatta week starts with a practice race around Kuah Harbour (pictured above) which is just off Langkawi island’s biggest town, Kuah. For the 5 remaining race days, the teams compete on different courses in various locations around Langkawi’s coast and other nearby islands. Most of the evenings have organised dinners at the Royal Langkawi Yacht Club which is also when the awards are presented for the most recent races. The week culminates in the final awards and grand prize ceremony on Saturday night.

How do the actual races work?

Good question! At each race, the crew is meant to sail the predefined course in a bid to finish the fastest. The skipper, the boat’s captain, has to guide and instruct his crew to manoeuvre around the course to get to the finish line as quickly as possible. As for who’s competing, the regatta is open to six different boat classes, roughly characterised as different types of boats. However, the races themselves are class specific which means that in one race, only boats of the same class compete with each other. That day, the same racecourse will be used by all classes with each class being flagged off at a different start time.

Track time with Toro Timer

Toro helps remote teams stay productive no matter where they are.

Get early access

In theory, the scoring is pretty straightforward: whoever finishes the race in the shortest time wins and the higher up you are in position, the better the score. However, calculating the winner is a little more complex than that. Though the races are class-specific, a time corrector known as a rating, and sometimes called a handicap, is also used to allow different boat classes to compete with each other despite differences in size and speed. At RLIR, the IRC rating rule is used to calculate the time corrector, known as a TCC rating, based on a boat’s measurements such as length, weight and sail area amongst other things. At the end of each race, the boat’s elapsed race time is then multiplied by its TCC to calculate the vessels corrected time. Whoever has the shortest corrected time is declared the winner. At the awards ceremonies, crews are then recognised as winners for each class as well as with a rating-corrected time.

So what does Stampede do for RLIR?

Our team has been involved with designing and maintaining the regatta website for years! 2020 is actually RLIR’s 18th year running and Stampede’s 15th as part of the landlubber digital crew. The bulk of the work usually involves maintenance and making sure that the site is technologically up to date and timely in its content. 2015, on the other hand, was special because we redesigned the Langkawi Regatta website to capture and retain the spirit of the event while making sure that it had longevity. Here, we’ll tell you a little about how the team planned and executed the redesign and how the rest of the maintenance work is otherwise split into three distinct phases: Before, during and after RLIR.

Redesigning the website

The current website was redesigned in 2015 and yet the look, feel and features remain relevant and fresh 5 years later. Our team’s design decisions were informed by a need to recreate the aura of the live event in addition to using data from the website and feedback from the RLIR team to inform its functional elements.

The team created the design from scratch, taking care to deliver the highlights and excitement of the race. This time, we also chose to give a rare glimpse of the people behind the race itself: from the yachts themselves, crews, race officers, volunteers all the way to the organising committee. Since the regatta is an annual reunion of sorts for the international yachting community, it was important for us to convey that sense of genial familiarity, synonymous with the Langkawi Regatta brand, to its online presence. Powered by WordPress, the regatta website is also geared to support fast and efficient updates as the event happens. This includes a live Newsfeed wall for everyone to watch in real time.

Other essential design considerations were data-informed. Based on the Langkawi Regatta website analytics (above) for multiple years, it’s clear that the vast majority of our website users are aged 40 and above. A large chunk of our users also look at the website on their mobile devices. Equipped with this data, we designed the website to ensure that everything from navigation through to font sizes and notifications is optimised for this demographic and for mobile viewing. This is a classic case of using available information on your users to inform design decisions and make meaningful and relevant experiences for them. As a result, we are still using the 2015 design today!

Before the Regatta

We usually spend the six months leading up to the race updating the RLIR website in preparation for the main event. This involves making sure that items such as SEO and plugins are the most recent. The website is a central hub for the participants and media to learn more about what’s in store so it’s imperative that we put up the information promptly.

Our standard practice is to update important information in less than 30 minutes from the time that we receive it. Vital information such as the regatta dates, crew availability (a listing page which shows people looking to crew on a boat) and banner images are some of the items that need to be done straight away followed by enabling the entry forms for participant registration. Other critical items like the schedule, sailing rules, scoring, penalty system and fees also need to go up so that participants can start planning their strategy and media can begin writing about the event. On the other hand, less critical updates such as updating the hotel rates, entrants list and unofficial press is updated within 2 hours. The pace of updating picks up considerably in December as it’s a month before the start of RLIR. This is when we receive the most content updates from the RLYC team.

During RLIR

This marks the most exciting and hectic period for us and the RLIR team. What sets this phase apart from the others is that it requires our team to be at RLYC and updating the website live. Besides the updates coming in thick and fast, sudden changes sometimes need to be made. The website’s traffic peaks during the event so it’s important that the updates are made swiftly by the onsite team so that web visitors can get the latest news.

The Team

Every year, we send an RLIR team that consists of two Front End Developers (FEDs) and a Designer. This year, we’ve sent our Senior FED Iwan Hakim and FED Sani Halid along with and Saiful Hamdan, UX Designer, to handle the event. Iwan, is the team lead and an RLIR veteran with more than a decade’s worth of experience. Besides having valuable knowledge from working on so many Langkawi regattas, he’s also the linchpin of our team connecting many participants, committee members to race officers and returning volunteers. He’s even rubbed shoulders with some of the VIPs! Since he has an established relationship working with the RLIR team, he can then manage the workload and delegate which allows the team members to focus on execution.

The work assigned to each team member is based on their areas of expertise. FEDs are assigned to update the site during the event which includes daily results, highlights, videos, photo gallery and email newsletter while the designer is assigned to process the images passed to us from RLIR’s photographer. The team also sits in the media room where they can have access to good and stable internet for the updates.

A day at the regatta: Round the clock work

A typical day at the regatta actually requires continuous work from early in the morning until the wee hours. This is because news, updates and pictures come in at different times and need to be sent out throughout the day and before the next day starts. The first thing we attend to is putting up vital information and last minute instructions onto the website. This can happen as early as 6 am so that the participants get a chance to read it before they head out to the racecourse at 7 am.

After breakfast, the Stampede team starts actively looking for content that can be used on the website’s RLIR timeline page. This page provides a summary of everything that happened on the day and includes results, information, highlights and much more and will need to be updated throughout the day. Meanwhile, the other team members will start preparing the day’s race results which are released around 12 pm. Once we receive the results from the race officers, they are updated on the website as soon as possible so that everyone can access them on the mobile friendly site. Once the results are finalised, they are printed and displayed on the notice board at RLYC for our media partners.

Throughout this process, it is crucial that we ensure that the results are accurate before they go up on the site. We also try to get all the latest information, especially the race results, up before everyone gets back from the day’s races. This is so the participants can see them and celebrate immediately. Prompt updates and a stable website are especially helpful for participants as they can quickly check the results and file a protest if necessary. A protest is a formal submission made within a specified time to the jury by someone who noticed when a team or individual violated the rules of the race. If found to be true, the protest could lead to a change of results.

When the evening rolls around, we can start processing the rest of the day’s content updates. There is usually a lull after updating the results as the official photographer can only pass us the race images around midnight. This is because they are out at sea all day taking photos and need to shoot the evening awards ceremonies after. However, once the photos are passed to us, our designer can then go through the images, select the best ones and then optimise them for website use for the photo gallery, email newsletter (also known as an EDM) and highlights. We also add items to the RLIR Timeline including social media posts from Facebook, Instagram and Twitter to give the website visitors a peek at the day’s events as well as behind the scenes to hype up regatta. This makes it easy for everyone to find out everything quickly and from one place.

The last item we need to prepare and send out before calling it a night is the daily newsletter blast that gives an overview of what happened that day and contains videos from our media partners. The newsletter is especially important as it’s the main source of news for the people and family members who couldn’t attend the regatta. Our Mailchimp analytics also show that since it’s sent late at night, it becomes the first thing they open in the morning to view yesterday’s photos and videos to catch up with the race before gearing up for the day.

All in all, working all throughout the day and then waiting to upload the day’s photos at night which means long hours and sleepiness in the mornings. Needless to say, this can all be pretty gruelling. So how do we beat sleep? Well, we don’t just use tape to hold our eyelids open! To make sure that everyone gets enough rest, we rotate the team members so that someone is always working while the others sleep. We find this works pretty well. We also directly inject, I mean drink, our fresh coffee in the mornings from the Starbucks nearby to give us a kick start. Sometimes Shaza, our UX Principal who lives in, Langkawi actually makes a Starbies Javachip Frap delivery to the team before returning to Mission Control to monitor the website.

What we get to experience at RLIR

It’s not all work and no play though. Regatta is an incredible experience because we get to meet new people and learn about the world of sailing. There are always opportunities to connect with new people at events and RLIR is no exception. For example, we work closely with volunteers where there tend to be new faces every year so we get to meet a wide variety of people every time. In comparison, the media teams tend to have less turnover so we get to see familiar faces so each regatta is always a big reunion with lots of old friends.

Most people also don’t get the opportunity to watch the race up close but we’re lucky to be able to do so. At least once during regatta week, our team hops on an RLIR charter boats which zooms out to sea so we can watch the race up close. The most interesting part of the race is watching when the yachts are turning around a buoy. It’s always a moment where the crews have to work together and move around in synchrony to make the turn. Truly teamwork at its best!

We’re also lucky to have the RLIR personnel and volunteers onboard with us who answer our questions and tell us about what’s happening. By working the event, we learn a lot about sailing. From the terms to the boat structure, racing rules, scoring systems the list is endless. Learning about this also helps us do our work since we understand the lingo and can talk to others within the sailing community. Overall, it’s just an awesome getting to watch the teams in action from the water with the wind in our hair and sunshine on our face.

After the Regatta

Once the regatta is done and dusted, our priority is to notify web visitors that the event has finished. We update the site with a congratulatory message to the winners and a thank you to the participants and sponsors while displaying the full result on the homepage. We then convert the RLIR Timeline so it’s of a past regatta. By doing this, web visitors who missed the proverbial boat can still find out what happened during race week. Compared to our work during the regatta, this period is a cakewalk with the fewest updates and the least work.

RLIR is an exciting and challenging opportunity for our team to plan, coordinate and execute a year-long web campaign. Much like when the boats go round a buoy, we need to work with each other closely and communicate with the RLIR team before, during and after the regatta to make sure that the website and event is a success. We wouldn’t be able to make it through one night of the event without having a clear process and posting schedule nor a sleep plan! It also requires attention to detail and seamless delivery while maintaining the flexibility required to deal with sudden changes. Thankfully, we have the opportunity every year to meet our users and hear their ideas for how to improve the RLIR website further. Nothing beats a reality check like talking to real sailors and sailing enthusiasts.

To find out what we’ve been talking about this whole blog post, raise yer sails and head on over to langkawiregatta.com for our team’s real-time web coverage! Keep up with our scurvy team on our Facebook page, Instagram and Twitter.

The post Avast! Behind the Sails at the Royal Langkawi International Regatta appeared first on Stampede: the strategic design & technology company.

Having empathy

UX wouldn’t exist without empathy. In UX, users are at the centre of everything we do. From empathising with a user’s motivations to knowing why they use a product in a certain way, a UX designer’s objective is to make sure that the product is useful for their users. This means truly understanding the end customer. Don’t, however, go chasing after clients like Tom Cruise did in Jerry Maguire. He kinda had the right idea but fell short in execution.

If UX designers didn’t understand a user’s real context, we’d just be making decisions from an air-conditioned room without a real grasp of the real situation. To ensure that we truly know what our users go through, we conduct ethnographic studies by experiencing the real contexts in which our users use the product.

Once, on a Stampede Oil & Gas project, we shadowed workers in an oil refinery over their 12 hour shift. We learned that we had to take into account the long and exhausting hours, hot conditions and clunky equipment. Would we have had any idea of what it was like without literally stepping into their boots? Probably not. But because we took the right steps to empathise with the plant workers’ unique challenges, we gained significant insights that informed our work.

Emotional intelligence

I’m sure you know a couple of people who magically know when you’re feeling rotten and how to make you feel better. Those friends probably have some kick-butt EQ. Having good or high Emotional Quotient (EQ), a.k.a. emotional intelligence, is useful for navigating relationships with people from different backgrounds, industries and roles.

Being able to quickly parse a person’s drives and concerns allows you to adjust your approach to them accordingly thus optimising your interactions with them. This becomes increasingly important the further you go up the UX totem pole as managers need to organise their clients and teams.

Besides the obvious benefits in day-to-day work relations, UX practitioners with high EQ can glean the truth by reading between the lines of what users’ may actually mean as opposed to what they say. This is especially useful during usability tests and user interviews where the interviewer has to dig for proverbial gold from users. Similarly, by sensing the general mood of the interviewee, the UX designer can control the flow of the conversation to unearth more insights.

Ability to articulate

Ever wondered how some people are just so good at explaining really hazy and confusing concepts? Just a little secret, it takes a lot of practice and plenty of linguistic elbow grease. UX can seem mysterious simply because it’s a broad category. The subjects it covers ranges from how a product makes you feel to the change in ROI when a button’s colour is updated. It’s therefore the job of the designer to explain these abstract concepts to the clients or workshop participants in understandable terms.

Designers also need to be able to weave together disparate narratives from multiple sources to create a coherent story. This goes hand-in-hand with articulating what a client is trying to express. Here, from the input of the clients, experts and workshop participants, the designer has to tease out information and identify where and what the pain points and opportunities.

Persuasive

Us UX designers are a charming bunch! We constantly use our persuasive [hypnotic] powers to evoke the right emotional experience and encourage users to complete specific objectives. From the business side, getting buy-in from relevant stakeholders is paramount.

We’re Hiring! Become our UI/UX Designer

We’re expanding our UX team and looking for UI/UX designers who believe in doing the right thing. Are you humble, hungry and smart? Check out this job description and apply!

View Job

When proposing a solution, designers need to make sure they’re solving the stakeholders’ problems while communicating the benefits and risks clearly. The ability to effectively repesent both the business and user interests is important to win stakeholder’s support. Doing this for different parties means speaking their language to keep the whole team focused on the end goal. It’s not always easy to tap dance your way through the Minefield of Differing Opinions™ but this is why a designer has to be persuasive enough to keep everyone onboard and on-track. This special ability especially will go a long way in cross-functional teams.

Persuasion doesn’t just stop at stakeholder management. Designers use persuasive design constantly to nudge users to stay motivated and complete their goals. Techniques such as progressive disclosure and some aspects of gamification work to encourage long-term engagement and the formation of habits as is often the case with e-commerce and health insurance.

Humility

In today’s culture that fetishises egocentricity, it’s easy to forget the importance of humility. This especially applies to UX designers who shouldn’t breeze in as experts shooting off design thinking sound bites. It’s usually the client or the business who are the experts as they’re the ones who have been working in the industry and on the product.

My role as a UX strategist, especially during workshops and design sprints, is to listen keenly and steer the conversation rather than dominate it. Designers bring a fresh perspective and reframe the questions and potential solutions after parsing the input from various parties. This enables us to facilitate discussions and only step out when necessary to highlight important elements.

—

Now, as you probably noticed, a lot of these skills aren’t mutually exclusive. Emotional intelligence and empathy form the foundational soft skills upon which being articulate, persuasive and humble are built. Because UX as a field is constantly evolving and follows in the wake of technological developments, it’s more important for aspiring UX designers to have the right attitude and soft skills rather than technical know-how as those can often only be developed over time. At least at first, UX designers need to tap into their soft skills and get used to wiggling their toes in other people’s shoes.

By the way, we’re hiring UI/UX designers! Check out the job description here. The application deadline is Friday 30 November 2018.

The post People Smarts: 5 Essential Soft Skills for UX Designers appeared first on Stampede: the strategic design & technology company.