#design_process

[eggpressonet]

Right Design; Design Right

Victor Ong - Head of Design (APAC) @ Bain & Co https://www.slideshare.net/KuldeepKulshreshtha/design-the-right-thing-and-then-design-things-right-uxsea-summit-2019

Bài này thực tế dựa trên mô hình double diamond (DD). Để hiểu trọn vẹn thì các bạn cần đọc về DD trước. https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond

Cũng như những bài khác thì việc design được Victor focus vào trọng tâm chính là nhu cầu người dùng (user needs) và mục tiêu kinh doanh (business objectives) thay vì tập trung vào lớp bề mặt (surface). Cũng trích dẫn lại mô hình 5 planes của Jesse James Garett (bạn nào muốn tìm hiểu sâu hơn thì tìm đọc cuốn Elements of UX Design của JJG)

Để tìm ra được phương án thiết kế tối ưu thì Victor chỉ ra có vài bước:

Do thám (Bloodhound): đổ nhiều công vào việc nghiên cứu tìm hiểu nhu cầu người dùng.

Giác quan thứ 6: Cảm nhận được xu hướng trước khi xu hướng trở nên bão hoà. Cái này cần sự quan sát và nhạy cảm tuyệt vời

Sức mạnh siêu nhiên: Làm nghiên cứu chính, nghiên cứu bổ sung, tổng hợp nghiên cứu, cân đối với mục tiêu kinh doanh, chèo lái chiến lược và tầm nhìn

Không gian chưa thám hiểm: dựa vào những gì đã biết để đưa ra chiến lược/con đường phía trường

Đoạn sau Victor không nói kĩ về DD, mình tóm tắt nhanh cho các bạn hiểu. Công việc design bao gồm 2 giai đoạn:

Tìm kiếm thu thập thông tin (thực hiện các biện pháp nghiên cứu và tổng hợp kết quả nghiên cứu)

Ra được phương án thiết kế (design solution) tối ưu (ý tưởng và triển khai)

Hình thoi (Diamond) có cấu trúc từ 1 điểm bên trái; mở rộng ra 2 điểm ở giữa; và cuối cùng hội tụ ở 1 điểm bên phải. Nó đại diện cho việc bạn bắt đầu từ một vấn đề cần giải quyết (problem need to be solved). Tiếp đó bạn tìm kiếm thông tin, nghiên cứu người dùng thị trường (mở rộng phạm vi).

Sau đó thu hẹp lại những insight cốt lõi về vấn đề cần giải quyết. Tiếp đó bắt đầu hình thoi thứ 2: Mở rộng để tìm các ý tưởng càng nhiều càng tốt. Cuối cùng vì phạm vi và nguồn lực triển khai có hạn nên sẽ hội tụ về một phương án cuối cùng phù hợp nhất và triển khai thiết kế chi tiết (craftmanship) cho phương án này.

Nếu kéo dài hình thoi thứ nhất thì chúng ta dành nhiều thời gian hơn cho việc nghiên cứu hoặc làm mẫu thử để tìm hiểu nhu cầu.

Nếu kéo dài hình thoi thứ hai thì chúng ta dành nhiều thời hơn việc tập trung vào phần triển khai giải pháp.

Tổng thể thì Victor cũng nhấn mạnh rằng: thiết kế đáp ứng nhu cầu người dùng quan trọng hơn là làm cho thiết kế bắt mắt

[hoseinkm89]

🖌️فرآیند طراحی بر اساس استاندارد CIW برای طراحی فرآیندهای مختلفی معرفی شده که هر کدام مزایا و معایبی دارند. به نظر شما فرآیند پیش رو چقدر کاربردیست؟ -- منتظر نظرهای شما هستم❤️ -- #CIW #Design_process #Workflow #Planning -- -- 👈 دوستان خود را دعوت کنید 🌷 -- -- 🆔@HK_UIUX 🆔@HK_UIUX 🆔@HK_UIUX -- -- #UIdesign #UXDesign #Interface #Design #UI #UX#Application #Minimalism #Interface_design #Art #Designer #UX_Designer #UI_Designer #sketch #Figma #Photoshop #color #طراحی #طراحی_سایت #طراحی_تجربه_کاربری #مینیمالیسم #گرافیک #هنر #طراحی_گرافیک (at Tehran, Iran) https://www.instagram.com/p/CD4EjHSARrp/?igshid=yluo7k1exawd

[waydespencil]

"From Soup to Nuts" or From idea to fruition. Thumbnails, cleaned layout, and final model. One of my earlier posts showed me building the 3D model. Next I'll try putting it in the Unreal Engine. Still rough around the edges but acceptable for being self taught... Onward! #ideation #illustration #design #3d_artist #3dmodeling #3d #3ds_max #productdesign #learning #cables #digitalart #digital_art #design_process (at Brockton, Massachusetts)

[pilaurice-photos]

@design_process #outtake #fat #numbers / on Instagram http://ift.tt/2qRb5pq

[designing-ivd-blog]

Week Four:  Design Play-Test 2

We met the same team, and explained the puzzles to them. We had our special guest, David solve the puzzles. Received feedback from both of them and modifications were included.

[ef415-blog-blog]

Fitting UX Process to Agile

Your team has created personas and segments. And (maybe) you've got a Market Requirements Document and/or Business Goals. So, what's next in product development? A general outline...

New Project Process

1. Gather requirements - Do this well before dev begins in order to get design traction

Hold Design Inception / Design Studio attended by stakeholders

It's working session where "requirements" are recorded as users stories. It's an internal user-centric focus group that answers the question: what does the user want/need? 

Identify lead leaders (UX, Dev, PM).

Artifacts: a framework of stories, epics, idealized workflows

2. First pass architecture - In an iterative development, some things are easier to change than others. Architecture can prove difficult to overhaul. Start with an early pass. Share with: Product and Dev. Architecture artifacts help convey vision to the dev team. And their feedback around technical capabilities and feasibility at this point is invaluable.

3. Build prototype -OR- track towards minimum viable product - defining and MVP is like defining a prototype in many ways.

4. User Testing Research - Do it during development

For concept testing: concept scenarios and test storyboards or paper

For usability: task-based scenarios and click-able prototypes.

5. Analyze UT results - decide what to fix and fix it (fixes will vary in size and may require design and dev stories or just the latter).

6. Design - fill in the framework from #1 above. Some areas will have already been designed during #2 and #3. Size remaining areas/tasks/stories and plan them across sprints (at the beginning of the sprint; just like dev stories).

7. Iterate, iterate, iterate.

Thanks for reading,

EF

[designing-ivd-blog]

Week Three: Puzzle Sequence Refinement and Delivery

With the feedback received from the last week’s test-play we further developed the puzzles and linked them to each other. As a bonus, we got feedback from David on our finally sewed up puzzle kit.

[designing-ivd-blog]

Week Two:  Design Play-Test 1

By combining and refining the puzzles developed in the previous week, we arrived at six puzzles.  We presented these finalized puzzles to the trans-media writing group as part of the design-play. These puzzles in detail were invisible message, sound related clues, mixing colours, solving a simple mathematical equation, professor’s notes/journals, and an aboriginal painting.

[designing-ivd-blog]

Week One-Concept Design

With reference to the developed concept from the brief and experiences from the ‘Escape hunt’ game we started brainstorming and we came up with many ideas. Initially, in our puzzles we focused on machines, languages and colour as we wanted to tackle different skills of players.

[ef415-blog-blog]

What It Takes to Get "Simple, Clean Design" (Or It's a Long Way to the Top if You Wanna Rock n' Roll)

In the immortal words of ACDC: "It's a long way to the top if you wanna rock and roll...". And getting to great UX is no different. "Why", you might ask, "I mean, I really just want something 'simple'. I don't need complex design or information architecture".  The answer to this question, of course, is: It takes work to get to something "simple". (Of course, I'm not talking about changing the button from blue to green here, I'm talking about software features or building something from scratch). Getting to "simple and clean" takes getting all the complexity out there (the variations and the requirements), distilling it down, and then marching down an agreed-upon path of what to design. Yes. All these things.  "...I tell you folks, it's harder than it looks...".

One of the biggest pieces is really the thinking and planning around what to design. Especially at the beginning of a large project. This is why building design stories and a conceptual model are key. I agree with Austin Govella who said the "design" piece itself is straightforward, even somewhat easy. It's figuring out what to design -- in a user-centric way, i.e., why is this useful, usable and meaningful for the user --- that's the tricky part. The benefits for stakeholders include: knowing what will be designed prior to "delivery" and saving time/money (sometimes lots of it) by avoiding re-work. The list could go on.

For a new feature or project, basically anything with multiple states or way finding (a flow), UX can become just as complex (and time-consuming) as the engineering effort to implement it. The ideation, planning and thinking are the big effort. And one dark secret is if you don't plan (by plan I mean model/ideate/design) a given "UI" or interaction, your engineering team will have to do it at least on some level. They will either noodle on it for some time then come to you (possibly frustrated) asking for vision and/or implement something in a vacuum, the results ranging from decent to Frankensteinian. Either way, precious time is lost and product quality is likely to suffer. The good news is there are some fairly simple ways to avoid the above (Yes, we will get to solutions, always)...

What about the business side of things? Business and other stakeholders can take heart in knowing:

Creating well-designed software is just as tough for your competition

Simple communication and alignment of business goals and user goals will provide direction and empower teams to their jobs done. It can go a long way towards getting your software "shipped".

OK, so how do we get the job done? To get more into the nitty-gritty of the process, see recommended reading below, and check out my post of Fitting UX Process into Agile.

"If you think it's easy doin' one night stands, try playin' in a rock roll band... It's a long way to the top if you wanna rock and roll..."

Thanks for reading,

EF

And remember...

Recommended - Marty Cagan: Design vs. Implementation and Project Discovery Plan  Austin Govella: UX + Agile: 6 Strategies and Parallel Workstreams  Anders Ramsay: Agile UX vs. Lean UX