Moving forward - What’s in a job description anyway?

Being a job seeker again has made me realise several things — one of which is that job descriptions for design roles are largely the same. You read 5, and you’ve probably read 90% of them. Call a designer by any other name, but they seem to be the same rose inside. 🌹

I also get asked by recruiters (and concerned friends) a lot about what I’m looking in my next role. The first couple of times the question came up, I struggled a little, because so much of what I want to do doesn’t fall neatly into a single role or description. As a designer, I started out in visual design then moved to UX, and at the same time, I also dabbled in quite a fair bit of research and management.

When I tendered my resignation, a kind mentor came to speak with me. I told her that I wanted to specialise, and she very nicely persuaded me not to. She had come from decades of experiences in various verticals and industries, and it was this amalgamation of experiences that trained and helped her in her executive career.

I remembered coming out of that conversation, moved and a little relieved that okay, maybe it’s all right to invest more time and effort in building lateral skills.

I had been hoping that somewhere, in a job description somewhere, that there will be the explicitly stated flexibility to jump in and out of roles and functions.

But that’s silly.

I don’t need something like that to be prescribed.

So, a note to myself, a JD is just a JD.

Building my own framework

A younger me would scoff at this — a process, a framework, hmph. Design and good ideas don’t belong in a process; they spring forth from creativity, imagination, daydreams, and talent! 🙄

As a young designer, I would go straight to Photoshop and start designing; I did minimal research — just enough to get the creative juices going — and my focus was on being fast and doing more so I could meet deadlines. Luckily, I had good seniors and bosses who made sure that the work delivered were up to standard and achieved the desired outcomes.

Well, an older/present me is scoffing at the younger me. Firstly, for thinking that I did not have a process. A bad process does not equate no process.

So, (a healthy amount of) shame on me for not recognising this, and for missing out numerous opportunities to improve my process and power up as a designer. While my process has changed since then, a lot of these changes were, more often than not, instituted by someone else. If I had been more deliberate and strategic about these changes, I would be able to get better and faster at identifying and solving problems (which is ironically what I was trying to achieve in the first place). Not to mention, I would also probably save myself a ton of time and angst.

Also, how mistaken I was about design and ideas! The Dunning-Kruger effect was in full force.

Dunning-Kruger.png

Indeed, ideas can come from anywhere and everywhere, and everyone thinks and conceptualises differently. After a couple of years, I started to get an inkling of what worked for me. And now, more than 10 years later in the industry, I have a pretty decent idea of what inspires me. For me, I am most inspired by real-life observations and constraints. The former is no surprise — I’m in UX after all — and the latter, let’s just say that when people or systems throw spanners, I’m all for tossing them back.

What I have also realised, is that having a good idea is nowhere near enough. Without a process to refine and expand upon it, a good idea is nothing more than just that. Much of design work has evolved dramatically in the last couple of years — digital used to be mostly advertising’s less developed twin — and with the ever-changing shifts from mobile-first to digital-first to content-first and now to customer-first, there is increasingly more to consider when designing and enabling a digital product.

As it was, this past decade of fast-moving technologies and user behavioural changes lined up pretty well with my career as a designer*. The mountain of design considerations grew faster than I could work. Reading up on trends, researching new patterns and design approaches, and applying them took time. Waiting for the verdict to come in while the rest of the design world moved on to new shiny products/tech/trends tested patience. Persuading people and coaxing systems tested tenacity. (*I’m not unique, of course; fellow designers who started out in the mid-2000s would likely uncover similar parallels.)

As I grew as a designer and took on more complex projects and more responsibilities, I realised that I needed a more structured approach to tackling these projects. I needed to be more disciplined in applying my own heuristics, and gasp, I needed a damn framework for myself.

• • •

A framework allows me to unpack a problem in a systematic way. It puts in place a checklist and a list of questions, activities, and processes.

You may ask, wouldn’t something like this hamper creativity? Wouldn’t it be too inflexible to allow a free flow of ideas? Those were my worries too! But creating your own framework is about leveraging your strengths and natural inclinations, and then hacking them for better productivity and results.

EmergeneticsProfile.png

When I took the Emergenetics profiling test as part of a work initiative, my thinking preference for Structure was a measly 6% — my brain apparently dislikes guidelines, predictability, and practicality. My thought and ideation processes are naturally predisposed towards the conceptual, experimental, and unusual. Great news for a designer, sure, but my brain clearly needs a push in the getting-things-done domain. Time to exercise the Analytical (43%) part of my brain.

Having a framework ensures that I don’t just take the easy shortcuts, and that I apply the same lens and rigour to all ideas and people, and that I take the time to deliberate, plan, and execute. It is a logical, findable (aka easily accessible) internal system to house the techniques and lessons I’ve learned. For some people, this comes naturally. For me, I have to learn how to herd.

There is less vagueness about the what’s to do, and I get to spend more time on the why’s and how’s. I like that my framework provides a certain predictability, which oddly then affords me greater control and clarity over my creative process.

• • •

So here’s a little peek at my framework. It is a distillation of learnings from the projects I’ve worked on, and therefore mostly design-orientated. It is neither complete, nor is it thorough. Some of it is aspirational, and I definitely need to be more conscientious in my application. As I’m writing this, I’m also taking the chance to review and improve.

Discover, Execute, Finish

This isn’t actually mapped to a typical project timeline, though it may seem that way. The three phases — Discover, Execute, Finish — are used for one single part/phase/activity of a project. For each phase, I go quickly through a series of questions:

Reflection: Have I done this before? How do I do better this time? What happened the last time?

Objectives: Why is this necessary?

Activities: What are the possible activities that need to happen for me to understand the reasons above and to validate them? What are the possible roadblocks?

People: Who can I work with on this? What’s in it for them?

Results: What do I need to move forward?

It’s a long list. While they manifest as questions here, I use the above as reminders (some of these have their own bulleted lists!). Most of them eventually turn into deliverables or action items. Having considered the above, what happens is that I’m ready to answer questions and defend our work (I learned this the hard way).

Discover.png

For example, a brief has just come in and I need to figure out how to run research — what kind of research is required, how to run it, and who should be involved.

1. Discover: Laying it out

Reflection: The last project didn’t have time for any user research and we had only a competitive analysis and expert review of our existing product. We then ran into some problems during prioritisation; we only had business and technical input, and we were not able to sufficiently support some of our design decisions because we did not have user input.

Objective: Ensure there is enough time to get feedback from actual users, and to run through with product owners for alignment before starting any design.

Activities/People: Determine and confirm all research activities, then create a research plan and schedule where we will be able to run the standard research protocol. This should include reviewing user reviews on the App / Play store and interviewing #X users from the identified target segments. Also, prepare to engage agency for user recruitment, incentivisation… etc.

Identify resource requirements, then discuss with the leads and project managers for resource availability, and engage the available people for the planned activities.

Results: Research plan approval and commencement by end-January.

Execute.png

2. Execute: Getting it done

Reflection: Not everyone knew what was happening during the week of user interviews. There wasn’t enough hands on deck, and the interviews took up way too much time, which affected the time we allocated for other research activities.

Objective: Ensure everyone knows what they need to do, and why it’s needed.

Activities/People: For each research activity, prepare a dashboard that includes a checklist and mini timeline. Check against the checklist and identify a rep for each of the activities, ensure that their schedule is available and that they get sufficient prep and support. Kick off research with a briefing for everyone.

Results: Close all research activities before mid-February.

Finish.png

3. Finish: Crossing this off the to-do list

Reflection: Our findings were pretty generic, and did not yield enough actionable insights. We ran out of time and did not sufficiently consolidate our findings before we started on design.

Objective: Ensure that our findings are substantiated, and can be translated into actionable recommendations.

Activities/People: Check in with respective reps on completion status, perform additional research, do a sanity check for our recommendations with tech, prepare presentation deck, update or re-scope project if necessary.

Results: Synthesise all research findings and come up with actionable design recommendations by mid-February. Finalise design proposal and present to management.

😗So it goes something like that, and this is just about planning research. Design life gets a little crazy, so it’s good / always better to have a list to check against and ensure that I’ve covered the essentials. Always starting with reflection means that I force myself to take a little time to look back; I can definitely just remember to do it, but having it explicit in my framework makes it harder for me to forget or ignore.

With the great deal of activity going on, just the act of answering and documenting these questions usually creates more clarity, which in turn lightens my cognitive load. Accordingly, I get more headspace (though not necessarily time) to think about more interesting stuff!

• • •

We are not static beings. The brain is plastic, and our memories are malleable. What I remember as unproductive could very well be the ideal way of working at that time. I have no doubt learned from fumbling along, screwing up, and making mistakes. I wouldn’t know to consciously reflect and learn from these mistakes if I don’t have the history or my past work experiences to compare with.

Writing this has been clarifying. It feels good to untangle thoughts (this has been a little long, hasn’t it?) and commit.