đź’ˇ Common Misconceptions about designing online things
I spent the last 6 years of my life producing online courseware for universities, corporates and charities. I want to share 6 takeaways that I’ve learnt from the 100’s of projects I’ve worked on during my time at Smart Sparrow.
1.
Messy Process = Clean Results
Clean Process = Messy Results
People wrongly assume that a clean production process will lead to a clean end product. The opposite is true. Impressive and polished end products are more often than not the result of a messy process where you explore many different options, double back on earlier decisions, where progress happens in fits and starts and often you throw out all your work and start again.
A major misconception is that a clean product must be the result of a clean process – where there were no delays, things proceeded smoothly from step to step and you don’t throw everything away and start again.
It sounds sensible to follow a “clean process”. Follow a predefined process? That sounds right! Proceed smoothly from step to step? Amazing! Backflipping on an earlier decision? Sounds like wasted time!
But here’s why a “clean process” is actually a bad idea.
At the beginning of a design process you lack knowledge of what is needed or even what is technically possible for some product or solution. In the process of designing and implementing a solution you learn more about your users and their needs, what is technically feasible or not and even whether you are optimising for the right thing. None of these things, you would have considered at the beginning. It is only in the process of grappling with the problem and crafting a solution that you start to understand the outlines of a problem area.
A “clean process” and schedule represent a series of one-way doors where there is no opportunity to reintegrate new learning as it comes in, which brings me onto my next point.
2.
Don’t be afraid to throw everything out and start again.
Do not be beholden to the sunk cost fallacy. Never feel like you are stuck with an earlier decision and don’t be afraid to redo things from scratch.
3.
Competition is better than cooperation
“Imagine what we could achieve if we pooled our resources” is often complete bullshit. The benefits of ‘pooling together resources’ are often overrated. People often have a bias towards cooperating even if the end results of cooperation are much poorer than competition. Cooperative decision making very easily slips into decisions by committee at which point you are constrained by the slowest common denominator.
Instead run mini-competitions where different designs, pathways are considered, evaluated and compared with each other.
4.
Do something. Don’t just talk about it
Describing an idea with words is often too vague and ambiguous to fully convey the meaning. Building something (a document, a visual design, a prototype) will get you further along in making a more considered decision.
This is especially true when dealing with someone who has less domain knowledge than you e.g. it’s okay for two graphic designers to discuss adding a colour gradient to a button but you cannot ask a client to imagine what that looks like. You have to show them.
5.
Embrace Novelty
Adding whimsical and fun elements to online learning modules can greatly improve the student experience and learning.
My first year accounting lecturer taught a boring subject- inventory cost accounting. Instead of following traditional teaching methods he made it interesting by bringing 2 watermelons and a barbie doll into class to illustrate different inventory systems. I still remember those lessons today.
Adding these novel elements can be even more effective than improvements to UI, UX. One teacher inserted a picture of a hamster in every piece of feedback they gave to students when they completed activities. There wasn’t any real purpose to a picture of a hamster. This wasn’t a design decision backed by pedagogical research. But it did give students something to talk about and provided an interesting touchpoint throughout their lessons.
One lecturer inserted a picture of a hamster in every piece of feedback in their online module.
6.
Clients judge visually
Clients must see things in order to appreciate them.
- Clients would judge project completion by the progression of visual designs. e.g. if we finished the visual design they mentally judged the project to be 80% done (despite the fact we still needed to implement the designs and QA test). If the visual design hadn’t been completed they would think the project was 0% done, even if we had a really strong well articulated design vision and understanding of the user. Sometimes we would send links of visual mockups to clients who would reply why they couldn’t click on anything and that the “lessons didn’t work”. The clients mistook the visual designs for the actual product itself.
- Clients would freak out over things like a broken CSS link, which would be trivial to us to fix (within seconds). But a broken CSS link would produce websites that look visually broken. The difference between something looking like it was VISUALLY broken and it working fine was as simple as updating the link for a CSS file.
- Clients would think that all the value of their decision making should be confined in the visuals process. The process can be largely broken down into the 3 parts: Ideas, Visuals, Execution. Most clients would exclusively focus on the middle part of the process – the visual design – i.e. suggesting different colours, asking for more pictures.
Whilst us as designers knew the true value in the process was in the first and last part of the process- the ideas and execution phases. If we developed a strong understanding of the users, the intended behaviours then we could easily produce a good visual design. But even after settling on a good visual design, implementing the design and ensuring it worked on different screen sizes and browsers was important to delivering value to the users.
7. Polish is the result of 100 tiny details each being a little better
I’ll add in an extra seventh one for good luck.
The best developer I ever worked with, taught me this lesson. A polished end product is the result of 100’s of tiny details each being optimised to be 2-3% better.
Most people believe the opposite – that a great product is derived from optimising for 2-3 large decisions.